questions following upcoming POSIX issue 8 release - iconv

Bruno Haible bruno@clisp.org
Wed Jun 12 00:36:00 GMT 2024


Eric Blake wrote:
> - https://austingroupbugs.net/view.php?id=1635

I added a couple of comments there, to explain the problem.
It is irritating to see that the Austin Group in defect 1007 apparently
acted like "we don't understand the rationale of the defect and we
don't think that GNU does worthy implementations, therefore let's
take what Solaris did and standardize that instead".

> Questions on whether iconv() needs to be able to distinguish between
> errors on the input (an invalid multibyte sequence) from errors on the
> output (no character available to properly represent the
> transliteration of the recognized input).

This is also a misunderstanding of the problem. For the standard's
purpose is would be OK to fail with EILSEQ for invalid input and
with some other errno value for unconvertible valid input; it would
"just" cause a problem to glibc, which cannot change its behaviour
after hundreds of applications have seen EILSEQ come out for the last
23 years.

The problem is that the applications want to get *notified* about
non-identical conversions, in a way that they can check the quality
(or possibly insert replacement characters of their own choice) and
then continue the conversion.

Bruno





More information about the Libc-alpha mailing list