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 MIME-Version: 1.0 To: Vik Heyndrickx CC: andrewc AT rosemail DOT rose DOT hp DOT com, Eli Zaretskii , 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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.