This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Mismatch among 8bit encodings having holes in them
- From: ash at contact dot bg
- To: libc-alpha at sourceware dot org
- Date: Thu, 20 Apr 2006 22:22:18 +0300
- Subject: Mismatch among 8bit encodings having holes in them
Hi guys,
There is a mismatch between whether some 8bit encodings have holes and the real
charmaps.
For example:
All these files:
libc/iconvdata/ibm437.c
libc/iconvdata/ibm861.c
libc/iconvdata/ibm862.c
libc/iconvdata/ibm863.c
libc/iconvdata/ibm865.c
have the following definition in them:
#define HAS_HOLES 1 /* Not all 256 character are defined. */
but when I look at their corresponding charmaps:
libc/localedata/charmaps/IBM437
libc/localedata/charmaps/IBM861
libc/localedata/charmaps/IBM862
libc/localedata/charmaps/IBM863
libc/localedata/charmaps/IBM865
all of them have 256 codepoints defined in them
---------------
cd libc/localedata/charmaps/
for i in IBM437 IBM86{1,2,3,5}; do echo -n $i ' -> '&& grep '^<U' $i | wc -l ; done
IBM437 -> 256
IBM861 -> 256
IBM862 -> 256
IBM863 -> 256
IBM865 -> 256
----------------
Can someone explain to me whether this is normal or a bug?
Kind regards:
al_shopov