Re: using the interfaces in ctype.h

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> Witness the start of this thread where it was suggested that the
> caller of the "ctype" APIs kill the ability of the compiler to detect
> incorrect usage while at the same time preventing the ability of the
> implementation to distinguish between EOF and 0xFF.

My understanding was that that was in the context of a case where the
argument was an element of a char buffer.  in that case, EOF _isn't_
possible (speaking conceptually) and thus a cast (or equivalent) is
reasonable.

When the argument comes from getc() or equivalent, rather than from
something already known to be storing only chars, the cast, or
equivalent, is not reasonable, and would likely introduce a bug.

But that difference is visible only to the caller, which is why the
cast-or-equivalent has to be done by the caller.

> The compiler warning everyone wants doesn't really help all that much
> (50% or less of cases I'd say),

It certainly has helped me.  Most of my calls to ctype.h interfaces
come from buffers known to contain chars, not straight from
unsigned-char-or-EOF interfaces like getc().  Perhaps I'm atypical in
this respect.

> Application programmers should be strongly encouraged to use the API
> as it is defined and they should not be encouraged to do funny things
> just to shut up the compiler.

True.  They should be encouraged to do things to correct the code,
which also shuts up the warning that highlighted the incorrect code.
You won't get "array subscript has type char" warnings if the argument
isn't of type char - and if it *is* of type char, EOFs have already
been filtered out (or, likely incorrectly, conflated with 0xff, but
ctype.h can't fix that after the fact).

> [...] when the programmer does end up passing EOF by mistake.

You appear to be under some kind of impression that passing EOF to the
ctype.h interfaces is a mistake.  WHile it may be so in any particular
case, it is not so in general; they are specced to operate on arguments
that are EOF or any value an unsigned char can assume.  It is, by
definition of isspace(), perfectly valid to pass EOF to isspace().

> Besides, the standards don't, so far as I can tell, require
> implementations to always return zero for all the is*() APIs when EOF
> is passed to them.

If true, this is a bug in the standard.  Anyone have a copy?  I don't.

> It just doesn't matter what these functions return when passed EOF --
> their result in that case is undefined anyway.  They are only
> required to accept EOF because it is and was common practice to
> directly pass the un-modified result of something like getc() to
> them.

If you believe that, you are living in a sufficiently different
universe from me that I see no point in continuing this conversation.

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