Re: sign of char on arm64

[Joerg Sonnenberger]

On Thu, Dec 14, 2017 at 12:17:56PM +0100, Mark Kettenis wrote:
> Pretty sure Linux uses the same defaults for the signedness of char as
> everybody else.  But since both signed and unsigned char have to work,
> it might very well be that the rust developers decided to ignore this
> largely historic inconsistency.  I doubt the performance difference is
> significant in any way for modern code.

The issue is not so much a question of performance, but whether zero or
sign extension is used in various places.

Joerg

Re: sign of char on arm64

[Sebastien Marie]

On Thu, Dec 14, 2017 at 12:17:56PM +0100, Mark Kettenis wrote:
> > >> 
> > >> I would certainly not expect NetBSD and FreeBSD to have "char" signed by
> > >> default.  afaik the powerpc, arm and arm64 ABIs define "char" as
> > >> unsigned.
> > >> 
> > >> FreeBSD documents those architectures as using unsigned char:
> > >> 
> > >>   
> > >> https://www.freebsd.org/cgi/man.cgi?query=arch=0=7=FreeBSD+12-current=default=html
> > >
> > > So it means the Rust libc definition for them is currently wrong, as
> > > 'char' is defined as 'i8' (signed byte) instead of 'u8' (unsigned byte).
> > > I will report it to FreeBSD people.
> > 
> > Maybe talk with the rust folks too, they probably have made that choice
> > for Linux on powerpc/arm*.
> 
> Pretty sure Linux uses the same defaults for the signedness of char as
> everybody else.  But since both signed and unsigned char have to work,
> it might very well be that the rust developers decided to ignore this
> largely historic inconsistency.  I doubt the performance difference is
> significant in any way for modern code.

Just to precise some points about Rust libc code.

If it should be manually maintained, it also have testsuite that
perform all sorts of checks (signedness, size, sturct offset...)

And it is because the testsuite reports to me signedness error (I
initially used 'i8' as all other platforms) that I investigated deeply
if it was expected or not.

The testsuite is automatically tested for each commit (using travis).
But for FreeBSD, only amd64 target is checked (it is done via qemu on
travis). And OpenBSD isn't checked at all.

So for other Linux like powerpc and arm, there are tested (and defined
to unsigned 'u8'). The definition should be right.
-- 
Sebastien Marie

Re: sign of char on arm64

[Mark Kettenis]

> From: Jeremie Courreges-Anglas 
> Date: Thu, 14 Dec 2017 12:06:05 +0100
> 
> On Wed, Dec 13 2017, Sebastien Marie  wrote:
> > First, thanks to all people that answered, off-list or not.
> >
> > On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas wrote:
> >> On Tue, Dec 12 2017, Sebastien Marie  wrote:
> >> 
> >> [...]
> >> 
> >> > But I would like confirmation because for all BSD where I have the
> >> > information, I always have a signed char (aarch64-freebsd,
> >> > powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
> >> >
> >> > Is it expected ?
> >> 
> >> I would certainly not expect NetBSD and FreeBSD to have "char" signed by
> >> default.  afaik the powerpc, arm and arm64 ABIs define "char" as
> >> unsigned.
> >> 
> >> FreeBSD documents those architectures as using unsigned char:
> >> 
> >>   
> >> https://www.freebsd.org/cgi/man.cgi?query=arch=0=7=FreeBSD+12-current=default=html
> >
> > So it means the Rust libc definition for them is currently wrong, as
> > 'char' is defined as 'i8' (signed byte) instead of 'u8' (unsigned byte).
> > I will report it to FreeBSD people.
> 
> Maybe talk with the rust folks too, they probably have made that choice
> for Linux on powerpc/arm*.

Pretty sure Linux uses the same defaults for the signedness of char as
everybody else.  But since both signed and unsigned char have to work,
it might very well be that the rust developers decided to ignore this
largely historic inconsistency.  I doubt the performance difference is
significant in any way for modern code.

Cheers,

Mark

Re: sign of char on arm64

[Jeremie Courreges-Anglas]

On Wed, Dec 13 2017, Sebastien Marie  wrote:
> First, thanks to all people that answered, off-list or not.
>
> On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas wrote:
>> On Tue, Dec 12 2017, Sebastien Marie  wrote:
>> 
>> [...]
>> 
>> > But I would like confirmation because for all BSD where I have the
>> > information, I always have a signed char (aarch64-freebsd,
>> > powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
>> >
>> > Is it expected ?
>> 
>> I would certainly not expect NetBSD and FreeBSD to have "char" signed by
>> default.  afaik the powerpc, arm and arm64 ABIs define "char" as
>> unsigned.
>> 
>> FreeBSD documents those architectures as using unsigned char:
>> 
>>   
>> https://www.freebsd.org/cgi/man.cgi?query=arch=0=7=FreeBSD+12-current=default=html
>
> So it means the Rust libc definition for them is currently wrong, as
> 'char' is defined as 'i8' (signed byte) instead of 'u8' (unsigned byte).
> I will report it to FreeBSD people.

Maybe talk with the rust folks too, they probably have made that choice
for Linux on powerpc/arm*.

>> afaik with clang and gcc you can just test whether __CHAR_UNSIGNED__ is
>> defined.
>
> Rust is a wonderfull land where all the standard libc definition has to
> be rewritten by hand (and kept in sync), so I haven't access to such
> compilation variable... 

Have fun. :)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: sign of char on arm64

[Sebastien Marie]

First, thanks to all people that answered, off-list or not.

On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas wrote:
> On Tue, Dec 12 2017, Sebastien Marie  wrote:
> 
> [...]
> 
> > But I would like confirmation because for all BSD where I have the
> > information, I always have a signed char (aarch64-freebsd,
> > powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
> >
> > Is it expected ?
> 
> I would certainly not expect NetBSD and FreeBSD to have "char" signed by
> default.  afaik the powerpc, arm and arm64 ABIs define "char" as
> unsigned.
> 
> FreeBSD documents those architectures as using unsigned char:
> 
>   
> https://www.freebsd.org/cgi/man.cgi?query=arch=0=7=FreeBSD+12-current=default=html

So it means the Rust libc definition for them is currently wrong, as
'char' is defined as 'i8' (signed byte) instead of 'u8' (unsigned byte).
I will report it to FreeBSD people.

> afaik with clang and gcc you can just test whether __CHAR_UNSIGNED__ is
> defined.

Rust is a wonderfull land where all the standard libc definition has to
be rewritten by hand (and kept in sync), so I haven't access to such
compilation variable... 

Thanks !
-- 
Sebastien Marie

Re: sign of char on arm64

[Jeremie Courreges-Anglas]

On Tue, Dec 12 2017, Sebastien Marie  wrote:

[...]

> But I would like confirmation because for all BSD where I have the
> information, I always have a signed char (aarch64-freebsd,
> powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
>
> Is it expected ?

I would certainly not expect NetBSD and FreeBSD to have "char" signed by
default.  afaik the powerpc, arm and arm64 ABIs define "char" as
unsigned.

FreeBSD documents those architectures as using unsigned char:

  
https://www.freebsd.org/cgi/man.cgi?query=arch=0=7=FreeBSD+12-current=default=html

afaik with clang and gcc you can just test whether __CHAR_UNSIGNED__ is
defined.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: sign of char on arm64

[Philip Guenther]

On Tue, Dec 12, 2017 at 10:44 AM, Sebastien Marie  wrote:
>
> While working on porting rust to arm64, I found something that seems a
> bit odd for me, and I would like to have confirmation that it is
> expected: the signess of char on arm64.

...

> But I would like confirmation because for all BSD where I have the
> information, I always have a signed char (aarch64-freebsd,
> powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
>
> Is it expected ?
>

Yes.  Note that powerpc-openbsd has char as unsigned.

Philip Guenther

Re: sign of char on arm64

[Theo de Raadt]

It is an artifact of the processor, not the operating system.

As a general rule (at least in the old days) this had to do with
how condition codes are updated, based upon each operation or
upon extra specific instructions... and this looseness fell out
of that.

> While working on porting rust to arm64, I found something that seems a
> bit odd for me, and I would like to have confirmation that it is
> expected: the signess of char on arm64.
> 
> In order to test the sign of 'char' (unsigned or signed), I use the
> following C program:
> 
> $ cat sign-of-char.c
> #include 
> 
> int
> main(int argc, char *argv[])
> {
>   printf("char:  %d\n", ((char) -1) < 0);
>   printf("signed char:   %d\n", ((signed char) -1) < 0);
>   printf("unsigned char: %d\n", ((unsigned char) -1) < 0);
>   return 0;
> }
> 
> on amd64, it reports:
> amd64$ cc sign-of-char.c -o sign-of-char && ./sign-of-char
> char:  1
> signed char:   1
> unsigned char: 0
> 
> so on amd64, 'char' is signed.
> 
> but on arm64, I get:
> arm64$ cc sign-of-char.c -o sign-of-char && ./sign-of-char
> char:  0
> signed char:   1
> unsigned char: 0
> 
> so on arm64 (aarch64), 'char' is unsigned.
> 
> 
> Per se, it isn't a problem. And if I correctly understood, the standard
> defines 3 distinct types ('char', 'signed char', and 'unsigned char')
> and the signess of 'char' is implementation defined.
> 
> Also, several architecture-OS already has char unsigned, for example:
> - aarch64-android
> - powerpc-linux
> - arm-linux
> 
> But I would like confirmation because for all BSD where I have the
> information, I always have a signed char (aarch64-freebsd,
> powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
> 
> Is it expected ?
> -- 
> Sebastien Marie
> 

sign of char on arm64

[Sebastien Marie]

Hi,

While working on porting rust to arm64, I found something that seems a
bit odd for me, and I would like to have confirmation that it is
expected: the signess of char on arm64.

In order to test the sign of 'char' (unsigned or signed), I use the
following C program:

$ cat sign-of-char.c
#include 

int
main(int argc, char *argv[])
{
printf("char:  %d\n", ((char) -1) < 0);
printf("signed char:   %d\n", ((signed char) -1) < 0);
printf("unsigned char: %d\n", ((unsigned char) -1) < 0);
return 0;
}

on amd64, it reports:
amd64$ cc sign-of-char.c -o sign-of-char && ./sign-of-char
char:  1
signed char:   1
unsigned char: 0

so on amd64, 'char' is signed.

but on arm64, I get:
arm64$ cc sign-of-char.c -o sign-of-char && ./sign-of-char
char:  0
signed char:   1
unsigned char: 0

so on arm64 (aarch64), 'char' is unsigned.


Per se, it isn't a problem. And if I correctly understood, the standard
defines 3 distinct types ('char', 'signed char', and 'unsigned char')
and the signess of 'char' is implementation defined.

Also, several architecture-OS already has char unsigned, for example:
- aarch64-android
- powerpc-linux
- arm-linux

But I would like confirmation because for all BSD where I have the
information, I always have a signed char (aarch64-freebsd,
powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.

Is it expected ?
-- 
Sebastien Marie