Mismatch among 8bit encodings having holes in them

[ash at contact dot bg]

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