Re: isspace() & i18n

["J. Johnston" <jjohnstn at cygnus dot com>]

egor duda wrote:
> 
> 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.
> 

You're correct.  The original designer of ctype.h should have used a pointer instead of the array so
this mess would never have occurred.  I am thinking it would be good to wean future programs off of
the array.

My proposal is to change ctype.h now to use a new pointer instead of _ctype_.  The pointer will get
set in ctype_.c.  In ctype_.c, we can use your GNUC code to set up _ctype_ to point to within the
expanded table.  Additionally, we set the new ctype pointer appropriately.  

For non-GNUC compilers, for a signed char implementation, we can declare two arrays, one the old
_ctype_ and another, the expanded table.  The new pointer will be set to point within the expanded
table.  Old code will continue to work as it always did and new code may take advantage of the new
table.  We place the old array declaration within an ifdef so platforms with small space
restrictions can simply choose not to include it.  Likewise, an ifdef could be added to determine if
the expanded table should be declared so again space-restrictive platforms have the ability to
exclude it.

-- Jeff J.