Sender:	bill AT taniwha DOT tssc DOT co DOT nz
Message-ID:	<34E3EF45.B2FB123A@taniwha.tssc.co.nz>
Date:	Fri, 13 Feb 1998 19:59:17 +1300
From:	Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
MIME-Version:	1.0
To:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
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> <34E2D52E DOT 3E71 AT rug DOT ac DOT be>

Vik Heyndrickx wrote:
> 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)

I have no idea about the standard (never seen it), but *I* feel that gcc
is right. To me, it seems that a signed variable sould be sign extended
and unsigned zero extended. It just doen't make sence any other way.

> 
> > 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 :-)

:)

Has anybody ever checked this with a M$ compiler? I'm actually curious
what MSC or VC++ does (I'ld be pleasantly supprised it it got it
right)..

Bill
-- 
Leave others their otherness.

- Raw text -