isascii (was: Another pitfall. Signed chars and ctype.h)

[Martin Weitzel]

In article <34540 at watmath.waterloo.edu> rbutterworth at watmath.waterloo.edu (Ray Butterworth) writes:
>In article <2448 at ditsyda.oz> evans at ditsyda.oz (Bruce Evans) writes:
>>Why doesn't ANSI C guarantee isdigit() (etc.) on *all* characters?
>
>Then the missing isascii() wouldn't even be needed.
>This was proposed to the Committee and rejected on the (incorrect)
>grounds that it couldn't be implemented without the macro's having
>to evaluate its arguments more than once.

As much as *I* understand ANSI-C, all characters of the "machine
character set" must have positive values. So IMHO problems with
isdigit() and the other <ctype.h>-stuff can only occur,

- if the compiler claims (only) to support ASCII,
- but you in fact use it for non-ASCII (eg ISO 8859).

This is not the problem of the compiler writers, because you
clearly could never assume, that isdigit() operates on EBCDIC
*and* ASCII at the same time. The pitty is, that the lower half
of ISO 8859 (or IBM extended ASCII as found on the 'typical' PC)
is 1:1 mapped into the international ASCII variant. So it becomes
not obvious, that an implementation written for ASCII is abused with
8-Bit char-s.

On the other side, if a compiler claims to *support* ISO 8859 it
has no other choice than to implement all plain char-s as unsigned
char. So, the problem should go away. Problems with istype()
seems to stem from abuse of an implementation on character sets,
it was not designed for!

(Nevertheless I *know*, that it is sometimes necessary to "abuse"
an implementation in this way, at least in europe with our umlaut-s.
If I abuse something, I should not complain it's broken. But the
warning in the original posting was valid, of course.)
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83