Hello Bruno, On Tue, Aug 28, 2007 at 12:05:46AM +0200, Bruno Haible wrote: > > > > 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.
Thank you for the clarifications. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
