Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<34E2D52E.3E71@rug.ac.be>
Date:	Thu, 12 Feb 1998 11:55:42 +0100
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
Cc:	andrewc AT rosemail DOT rose DOT hp DOT com, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
	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> <34E2ABD5 DOT 5537A24 AT taniwha DOT tssc DOT co DOT nz>

Bill Currie wrote:
> *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

Doesn't the standard say that any values represented in a smaller type,
should have the same value when promoted to a larger type which can
contain all values from that smaller type. Borland is very wrong.

The gnu compiler is right:
It first sign-extends the smaller signed type to the equivalent 'signed'
version of the larger type and then "turns the signedness" to the one of
the destination type. This is also the case for unsigned types being
promoted (sign-extension is zero-extension in this case)

> 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

Very, very, wrong. You can easily fix this by buying another compiler.
Strange that is wasn't even a M$ product :-)

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/

- Raw text -