Sender:	bill AT taniwha DOT tssc DOT co DOT nz
Message-ID:	<34E2ABD5.5537A24@taniwha.tssc.co.nz>
Date:	Thu, 12 Feb 1998 20:59:17 +1300
From:	Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
MIME-Version:	1.0
To:	andrewc AT rosemail DOT rose DOT hp DOT com
CC:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, Vik DOT Heyndrickx AT rug DOT ac DOT be,
	dj AT delorie DOT com, djgpp-workers AT delorie DOT com
Subject:	Re: char != unsigned char... sometimes, sigh (long)
References:	<199802111821 DOT AA191031265 AT typhoon DOT rose DOT hp DOT com>

Andrew Crabtree wrote:
> 
> 
> > It would be interesting to know why did GCC choose signed char for
> > x86.  Does anybody know?  Should we ask the GCC maintainers?  Or maybe
> > somebody can tell what are the advantages of signed char?
> This is just a guess, but presumably compatibility with an existing
> system (like BSD).  SIGNED_CHAR is the default for all x86 targets
> though, not just bsd derivatives, so maybe something else.

Also, Borland never defaulted to unsigned chars.  Every time I installed
one of their compilers (TC2, TC++1 & 3, BC3 & 3.1), the setting was
ALWAYS for signed chars (I never changed it either).

*HOWEVER* the difference between Borland's compilers and gcc is the way
they sign extend.  gcc sign extends if the smaller type is signed
(larger type irrelevant) but Borland *seemed* to base its sign extension
on the DESTINATION type (ie signed char->unsigned was zero extended but
unsigned char to signed was sign extended).  This caused me (and my
friend) a lot of grief (I was used to gcc's (intuitive) way). We kept
getting negative longs from an unsigned char. ie

unsigned char byte=0xff;
long dword=byte;
printf("%ld\n",dword);

would print -1, even if the second line was changed to "long
dword=(unsigned char)byte;".  I can't remeber how we fixed this
(probably byte&0xffUL, can't even remeber why it had to be long and not
unsigned long).

Bill
-- 
Leave others their otherness.

- Raw text -