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