Path: utzoo!attcan!uunet!lll-winken!lll-lcc!mordor!joyce!ames!pasteur!ucbvax!decwrl!hplabs!hpda!hp-sde!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.SDE.HP.COM (John Diamant)
Newsgroups: comp.windows.x
Subject: Re: 8bit xterm
Message-ID: <9740031@hpfclp.SDE.HP.COM>
Date: 9 Jun 88 06:33:25 GMT
References: <8805241750.AA11835@nirvana.cs.titech.junet>
Organization: HP SDE, Fort Collins, CO
Lines: 33

> >OK -- I've got something to start the discussion off with.  Why is String
> >(defined by X Toolkit) defined to be char * instead of unsigned char *,
> >and is there some reason it can't be changed? 

I've finally tracked down the source of all this unsigned char *.  The
problem is that the conv and ctype macros (tolower, isupper, etc) are
typically called with a char, however, their legal range is -1 to 255.
If an 8-bit char is passed to them, it will be converted to an int as
a negative number and be out of range (in fact, these macros are
typically implemented as array indices, thus the problem you mention below).
You can call them as toupper((unsigned char*) *p), but if you forget
to cast, the program will bomb in mysterious ways since it probably
indexes into a part of memory not in the array.  One solution to that
problem is to maintain your character data as unsigned char, but as
you mentioned, this has other problems.  By the way, I believe the
behavior I am describing is the Native Language Support as adopted
by X/OPEN.

> Indexing arrays must be done by masking off the sign bits: array[c & 0xff].
> This is often recognized by the compiler as a special case.  It is also a
> long-living tradition in C.

Writing non-portable programs is also a long-living tradition in C.  That
doesn't make it a good idea.  In fact, your suggestion of masking
the sign bits is non-portable.  You are assuming the size of your
char data type, which might not be 8 bits on some machines.   The
portable way to do this is to cast the data from char to unsigned char.
I realize most machines use 8-bit chars, but I don't think all of
them do.

John Diamant
Software Development Environments
Hewlett-Packard Co.		ARPA Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		UUCP:  {hplabs,hpfcla}!hpfclp!diamant