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