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 Mime-Version: 1.0 To: Bill Currie 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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 / \ /-_-_-_-_-_-_/