[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iconv: document not-fixed bugs, using POSIX terminology
From: |
Bruno Haible |
Subject: |
Re: iconv: document not-fixed bugs, using POSIX terminology |
Date: |
Sun, 03 Jan 2021 20:48:20 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-197-generic; KDE/5.18.0; x86_64; ; ) |
Hi Noah,
Thanks for the patch and explanations from
<https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg00172.html>.
> iconv.m4 clears HAVE_ICONV if it detects iconv() bugs. Docs list those bugs
> under "Portability problems fixed by Gnulib:". If changing HAVE_ICONV were
> enough to qualify as a fix, then "This function is missing on some platforms"
> would also belong under that heading. I'm proposing to move those bugs under
> "not fixed by Gnulib".
Good point. Yes, it doesn't belong under "fixed by Gnulib". But "not fixed by
Gnulib" is also not the right category. I'll list these under "handled by
Gnulib", with an extra explanation.
> Two of those iconv() bugs involve what POSIX calls "non-identical conversion".
> (GNU libc calls it "non-reversible conversion".) The gnulib docs and code
> comments use terms "failures" and "conversion errors", but these bugs don't
> entail the distinct POSIX concept of "error" or failure. Hence, I propose
> standardizing on the term "non-identical conversion".
"non-identical conversion" is a nonsensical term. Therefore it's better not
to use it. (Two objects can be identical if they are in the same mathematical
set. But when we use iconv, we are doing a mapping between the minimal byte
sequences of the input character set and the minimal byte sequences of the
destination character set; these are two different sets. If anyone uses
the term "identical" here, it would mean that the sets have an intersection,
and that the corresponding byte sequences are the same (e.g. like ISO-8859-1
and UTF-8 have, as intersection, the set of 1-byte sequences with values >= 0,
<= 0x7F).)
> The following patch has those changes. It also updates modules/iconv_open to
> check HAVE_ICONV where modules/iconv checks it.
Good point, yes.
> Incidentally, the AIX iconv() buffer overrun was gone no later than AIX
> 7100-03-02-1412. The non-POSIX-conforming return value remains as of AIX
> 7100-05-06-2028 and AIX 7200-04-01-1939. Moreover, IBM documents it:
> https://www.ibm.com/support/knowledgecenter/ssw_aix_72/i_bostechref/iconv.html
Thanks for the info. Reflected in the patches below.
Bruno
0001-iconv_open-Fix-module-description.patch
Description: Text Data
0002-iconv-h-Fix-module-description.patch
Description: Text Data
0003-iconv-iconv_open-Improve-documentation.patch
Description: Text Data
- Re: iconv: document not-fixed bugs, using POSIX terminology,
Bruno Haible <=