Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11) Assignee
	Description • 12 years ago

The support for non-default replacement characters in nsIConverterInputStream complicates the implementation but does not seem to have proper use cases.

We should remove support for non-default replacement characters either by changing the signature to drop the last parameter or by making the initialization with a non-default value throw.

	Masatoshi Kimura [:emk]
	Comment 1 • 12 years ago

We need to remove nsIUnicodeDecoder::GetCharacterForUnMapped() first. It does not return U+FFFD for Shift_JIS.

	Simon Montagu :smontagu
	Comment 2 • 12 years ago

IIANM this is orthogonal to bug 736438 and bug 593338. Those have minor interoperability and backward compatibility concerns, but I think this should just be fixed. It looks to as if nsIConverterOutputStream was written with support for non-default replacement character because U+FFFD is not necessarily expressable in the target encoding, and then nsIConverterInputStream got non-default replacement character support from a mistaken desire for consistency.

	Masatoshi Kimura [:emk]
	Comment 3 • 12 years ago

Most (AFAICT all) callers don't call GetCharacterForUnMapped() to get the default replacement character. They just use zero (meaning throw if fail) or nsIConverterInputStream::DEFAULT_REPLACEMENT_CHAR. And they cannot call GetCharacterForUnMapped() because the function is not scriptable.
If we remove the support for non-default replacement char without unifying the default replacement character, nsIConverterInputStream will begin failing to convert Shift_JIS for virtually all callers.

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11) Assignee
	Comment 4 • 7 years ago

Fixed by bug 1261841. If the caller asks for replacement, U+FFFD is used regardless of what character was requested.

	Masatoshi Kimura [:emk]
	Comment 5 • 7 years ago

The commit message should have been nsIConverterOutputStream, sorry.