🚀 go-pugleaf

In article <764@fisher.UUCP> djl@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)
-------------------------------------------------------------------------