lynx-dev type of isdigit etc. (was: Relatively mild dev13 build problems)

[Klaus Weide]

On Sun, 31 Oct 1999 address@hidden wrote:

> In a recent note, Klaus Weide said:
> 
> > Date: Sat, 30 Oct 1999 16:34:42 -0500 (CDT)
> > 
> > 
> > If any compiler is not happy with isdigit((unsigned char)c) it should
> > be ignored.
> > 
> > Well I don't know whether it's an actual problem anywhere.  It might
> > be for '\377' vs. EOF.  I don't know whether it's standard for these
> > macros to handle EOF specially - my man page says "must have the value
> > of an unsigned char or EOF".
> > 
> IIRC (I haven't ANSI handy today), the behavior of is*(c) is allowed
> to be undefined unless 0<=c<=127.  

It may be undefined for the "C locale", but other locales would of course
have it defined for 8-bit characters.

> It's plausible that an implementor
> might extend the domain either to 0<=c<==255 or to -128<=c<=127.  (The
> latter is the intuitive extension where that's the set of values of
> char.)

That may have been plausible at some point in the distant past, but now
the chice has been "fixed" by the standards:

FYI, a comment form GNU libc's ctype.h regarding that library's
implementation:

(The first sentence's "These" refers to macros that are used in the
expansion of is*(), to*().)

   These point into arrays of 384, so they can be indexed by any `unsigned
   char' value [0,255]; by EOF (-1); or by any `signed char' value
   [-128,-1).  ISO C requires that the ctype functions work for `unsigned
   char' values and for EOF; we also support negative `signed char' values
   for broken old programs.  The case conversion arrays are of `int's
   rather than `unsigned char's because tolower (EOF) must be EOF, which
   doesn't fit into an `unsigned char'.  But today more important is that
   the arrays are also used for multi-byte character sets.  */

So it accepts negative values only to cater for improper use.

   Klaus