unsigned char vs. signed char

[Ian Malone]

On 16 July 2014 10:28, Florian Weimer <fweimer at redhat.com> wrote:
> On 07/16/2014 11:00 AM, Jakub Jelinek wrote:
>>
>> On Wed, Jul 16, 2014 at 10:55:57AM +0200, Florian Weimer wrote:
>>>
>>> On 07/15/2014 07:22 PM, Adam Jackson wrote:
>>>>
>>>> On Tue, 2014-07-15 at 10:40 -0600, Orion Poplawski wrote:
>>>>>
>>>>> Did you know that "char" defaults to "signed char" on x86 but "unsigned
>>>>> char"
>>>>> on ppc and arm?  I didn't.
>>>>
>>>>
>>>> Yep, found that out the hard way.  It annoyed me enough that I went
>>>> digging in the gcc source to find the answer for all platforms:
>>>>
>>>> http://ajax.fedorapeople.org/is-char-signed-or-not.txt
>>>
>>>
>>> Any idea why aarch64 and ppc64le got this wrong?
>>
>>
>> Why is char == unsigned char wrong?  Because i?86/x86_64 do it
>> differently?
>
>
> Yes, it looks like a totally avoidable portability hazard.  iOS has signed
> chars as well, so even when considering current ARM, the natural choice is
> unclear.  Older ARMs couldn't perform sign-extending 8-bit loads in a single
> instruction, but that's true for historic x86, too, and yet even the old
> 16-bit compilers used signed chars.
>
> History aside, I assumed that the idea behind both architectures (aarch64
> and ppc64le) is to use it to run current general-purpose server loads, and
> those are predominantly x86 right now.  That's why picking unsigned chars
> puzzles me.
>

Implementation defined in all iterations of the C standard. End of story really.

-- 
imalone
http://ibmalone.blogspot.co.uk