Re: isspace() & i18n

[egor duda <deo at logos-m dot ru>]

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