Re: Suggested change of ctype.h

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> static __inline int islower(int c) {
>>         return (c < 0) ? 0 : (int)((_ctype_ + 1)[c] & _L);
> The above is broken, 'char' values between -128 and -1 can be lower
> case.

I don't think it's broken, at least not in the sense of violating the
spec.  char values in that range, on architectures where they exist,
may be lower case, but they are still invalid arguments to islower()
(except for EOF, if it collides with one of those 128 values), since
they are neither EOF nor possible values for an unsigned char.

> the behaviour (not the result) for other values is 'undefined'.

This means that (almost?) any behaviour, including Christos's proposed
behaviour, is permitted.

> Typically EOF is -1 and 0xff may be a valid character, the functions
> need to correctly discriminate between the two.

Which they do.  What they don't do is distinguish between EOF and
(signed char)0xff - but they're not required to; (signed char)0xff is
out of the domain of the functions, so there is no particular need to
distinguish it from anything else.  (That's for arches with 8-bit
two's-complement chars, which I think includes everything NetBSD
currently supports.)

Mind you, I don't like Christos's proposed change, but the reason isn't
that I think it violates ctype.h's interface spec; the reason is that I
_want_ warnings when I write code that (invalidly) passes plain char to
the ctype.h "functions".

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B