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