Hello Michael, > I'm not so sure of the details here, but maybe you are, since it relates to > iconv stuff. Can you confirm/disconfirm the > correctness of this part of the patch below: > > > -values are listed by the \fBiconv \-\-list\fP command, and all combinations > > +values are listed by the \fBiconv \-\-list\fP command, but not all > > combinations > ?
Glad that you ask. The patch is wrong; the text is correct as written years ago. > > For iconv_open.3, I had a look at the libc6 source code. > > The find_derivation function which is responsible for finding a path from > > the /from/ encoding to the /to/ encoding does not exclude that such > > a path does not exist, which back up the statement from `iconv --list`: > > > > The following list contain all the coded character sets known. This does > > not necessarily mean that all combinations of these names can be used for > > the FROM and TO command line parameters. One coded character set can be > > listed with several different names (aliases). Looking at the find_derivation function is fine, but you also need to look at the gconv-modules file. POSIX says that, *in general*, specific pairs (from, to) can be unsupported although 'from' and 'to' are supported. Here, we are talking about "For the GNU C library". And in the GNU C library, an encoding called "INTERNAL" is used as a pivot encoding: For all encodings, there is a converter from INTERNAL to the encoding and a converter in the opposite direction. This architecture guarantees that all combinations are supported. In fact, if someone would attempt to write an iconv module that "defines" an encoding by registering converters from/to another encoding, say, UTF-8 or GB18030, rather than INTERNAL, some features of iconv and multibyte processing would not work. Look at glibc's iconv/skeleton.c and you will understand. Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
