isspace() & i18n
egor duda
deo@logos-m.ru
Wed Jun 6 13:19:00 GMT 2001
Hi!
Wednesday, 06 June, 2001 J. Johnston jjohnstn@cygnus.com wrote:
>> >>The ISO C standard specifies is* facilities operate properly on
>> >>all values representable as type `char' and type `unsigned char'.
>> >>It depends on implementation whether char is signed or unsigned.
>> >>The is* facilities should operate on range [-128,256] on the
>> >>implementation where char is singied.
>>
>> CF> I agree. I think that this is the preferable solution.
>>
>> here's the patch that works ok for me. unfortunately, it relies on
>> nonstandard gccism, but at least it always initializes all _ctype_
>> array elements. when compiled with gcc, it additionally allows
>> [-128, -1] range for indices, too.
>>
JJ> Why not instead use the __CHAR_UNSIGNED__ flag? You could
JJ> initialize the table based on this flag and also check for it in
JJ> ctype.h. In ctype.h, the macros currently add +1 to _ctype_.
JJ> This offset would be determined by the flag. This removes the
JJ> check for gnuc and doesn't unnecessarily use additional storage
JJ> for unsigned char implementations.
JJ> For unsigned char platforms, the table would remain as it is and
JJ> the starting offset in ctype.h would remain +1.
no problems here.
JJ> For signed-char platforms, the table would be the new larger
JJ> table and the offset in ctype.h would be set to +128.
but here we may break backward compatibility. On platforms, where
isspace is implemented as macro, +1 offset is hardcoded into
application once it compiled. if _ctype_ is linked statically -- still
no problems, we just should keep offset in header and library in sync.
but when applications import _ctype_ from dynamic library, like they
do on cygwin, isspace() will fail. so we will be forced to recompile
all applications as we change the library.
Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19
More information about the Newlib
mailing list