Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!gatech!ncar!ames!pasteur!ucbvax!decwrl!hplabs!hpl-opus!hpccc!hp-sde!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.UUCP
Newsgroups: comp.windows.x
Subject: Re: 8bit xterm
Message-ID: <9740027@hpfclp.SDE.HP.COM>
Date: 1 Jun 88 20:00:41 GMT
References: <8805241750.AA11835@nirvana.cs.titech.junet>
Organization: HP SDE, Fort Collins, CO
Lines: 32
Posted: Wed Jun  1 16:00:41 1988

> I don't see why this is bad. How could you possibly lose the high bit if
> the character is signed?

I didn't mean that you lose the high bit, but you have to handle the
bogus sign extension.

>  Char-to-char transfers copy all 8 bits, even
> if you use ints as intermediates.  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.

Well, but char-to-int transfers also require masking off the sign bits,
as do any expressions involving chars (which may be cast to ints or longs
depending on the size of the other parts of the expression).  This strikes
me as pretty error-prone.

> I have a reason for *not* using unsigned characters: you'll get lint
> complaints and compiler errors or warnings on the use of perfectly safe
> functions like strcpy, which have 'char *' as their argument and return
> type.

I see your point.  It seems to me that either way, you're screwed.  The
only hope of a simple solution would have been if char would be defined
by the C language to be unsigned, but it isn't.  So, we're stuck with
having to do very careful casting no matter whether you use unsigned char *
or char *.  Now, I'm not really sure which way makes it easier overall.

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