XENIX 3.0 toupper() and tolower() broken
Richard L. Klappal
rlk at chinet.UUCP
Sat Sep 28 15:05:40 AEST 1985
In article <764 at fisher.UUCP> djl at fisher.UUCP (Dan Levin N6BZA ) writes:
>Seems that the XENIX 3.0 ctype.h has toupper() and tolower() defined as
>macros like this,...
>#define toupper(x) (ifsomething(x) ? dosomething(x) : (x))
>which breaks badly if (x) is autoincrement or autodecrement. Ie.
>toupper(s++) goes to (ifsomething(s++) ? donesomething(s++) : (s++)),
>which is clearly wrong.
>
>The fix is to ctype.h, to not use the trinary operator; or to use the
>libc versions instead (by #undef'ing toupper() and tolower());
>
>NB: This only holds for the Intel distribution, I have not checked the
>IBM XENIX 3.0 release.
>
>--
> ***dan
>
>{allegra,astrovax,princeton,twg}!fisher!djl
>The misplaced (You call *that* a ski slope??) Californian
This is not the only bug running around in toupper/tolower. While
some systems have this implementation, other versions (among which
is the Fortune) do not do any sanity check, they just add/subtract
0x20, thus transforming numerals into control codes or letters,
depending on the direction of conversion. Harbison & Steele warn
that toupper/tolower are inconsistant between versions if *NIX. and
indicate what they suggested (?? SYSV ?? ANSI ) recommendations are.
My answer has been my own local ROUTINES (not macros) named
'ucase' and 'lcase' that do the sanity check and compute the
result. It causes a little redundant code on machines that work
right, but is nice insurance anyplace they don't, without conflicting
with the internal names (viz. tolower or _tolower, etc).
(Apologies if I misspelled either of the names above, it doesn't
look right, but the book is upstairs)
--
Richard Klappal
UUCP: ..!ihnp4!chinet!uklpl!rlk | "Money is truthful. If a man
MCIMail: rklappal | speaks of his honor, make him
Compuserve: 74106,1021 | pay cash."
USPS: 1 S 299 Danby Street |
Villa Park IL 60181 | Lazarus Long
TEL: (312) 620-4988 | (aka R. Heinlein)
-------------------------------------------------------------------------
More information about the Net.bugs
mailing list