Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin From: martin@mwtech.UUCP (Martin Weitzel) Newsgroups: comp.lang.c Subject: Re: isascii (was: Another pitfall. Signed chars and ctype.h) Message-ID: <668@mwtech.UUCP> Date: 24 Feb 90 00:55:46 GMT References: <1990Feb12.043324.5259@sq.sq.com> <2448@ditsyda.oz> <34540@watmath.waterloo.edu> Reply-To: martin@mwtech.UUCP (Martin Weitzel) Organization: MIKROS Systemware, Darmstadt/W-Germany Lines: 36 In article <34540@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: >In article <2448@ditsyda.oz> evans@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 -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@mwtech.UUCP, voice: 49-(0)6151-6 56 83