Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Things are not as simple as they seems at first. -- Edward Thorp


devel / comp.unix.bsd.freebsd.misc / (resolved) Re: arm64 char conversion issue

SubjectAuthor
* arm64 char conversion issueMike Scott
+- Re: arm64 char conversion issuePeter van Hooft
`* Re: arm64 char conversion issueChristian Weisgerber
 `- (resolved) Re: arm64 char conversion issueMike Scott

1
arm64 char conversion issue

<st8f2h$bk8$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=137&group=comp.unix.bsd.freebsd.misc#137

  copy link   Newsgroups: comp.unix.bsd.freebsd.misc
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: usenet...@scottsonline.org.uk.invalid (Mike Scott)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: arm64 char conversion issue
Date: Mon, 31 Jan 2022 10:53:05 +0000
Organization: Scott family
Lines: 49
Message-ID: <st8f2h$bk8$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 31 Jan 2022 10:53:06 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8184df9da746037f13acfef0feb7add9";
logging-data="11912"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/PVznmOic/4EsllYwW+KcwzfdGn4p1aqo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Cancel-Lock: sha1:JToxrdkwC0RnId4R6dDSHsaDOTg=
Content-Language: en-GB
 by: Mike Scott - Mon, 31 Jan 2022 10:53 UTC

I've hit an interesting problem. This is on fdbsd13/arm64/rpi4, and
there's something amiss with char to int conversions. Or at least, a
difference from i386.

The immediate symptom is that spfmilter won't start - just says
'unrecognised option', with a seemingly empty string appended that's
actually 0xFF.

This comes from the getopt() loop, whose guts are

char c;
while ( ( c = getopt_long( argc, argv, shortopts, longopts, &idx ) ) !=
-1 ) {
......

It turns out that on the pi, the integer result from getopt is truncated
then zero-padded rather sign-extended, so the comparison is 0xFF != -1,
which always fails.

A simple test program like
char c = -1;
int x = c;
printf("c=%x x=%x\n", c, x);

gives on the rpi (it truncates)
c=ff x=ff

but on an i386 (fbsd11.4) (it sign-extends)
c=ffffffff x=ffffffff

Any thoughts please? This seems potentially a major gotcha. The
spfmilter code uses a char to hold getopt()'s result - as long as it
sign-extends, no issue: but truncation will cause an error. I see the
man page example for getopt uses an int, which is clearly safer.

I confess I've been away from C programming for so long, I forget what
the correct behaviour is. Any thoughts? Is spfmilter wrong, or is the
arm64 compiler wrong?

--
Mike Scott
Harlow, England

Re: arm64 char conversion issue

<slrnsvfnf7.nji.pjvh@xs9.xs4all.nl>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=138&group=comp.unix.bsd.freebsd.misc#138

  copy link   Newsgroups: comp.unix.bsd.freebsd.misc
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!ecngs!feeder2.ecngs.de!178.20.174.213.MISMATCH!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!nzpost2.xs4all.net!not-for-mail
Newsgroups: comp.unix.bsd.freebsd.misc
From: pjv...@xs9.xs4all.nl (Peter van Hooft)
Subject: Re: arm64 char conversion issue
References: <st8f2h$bk8$1@dont-email.me>
User-Agent: slrn/1.0.3 (Linux)
Message-ID: <slrnsvfnf7.nji.pjvh@xs9.xs4all.nl>
Date: 31 Jan 2022 13:02:31 GMT
Lines: 22
NNTP-Posting-Host: ab768060.usenet.xs4all.nl
X-Trace: G=dvdnk/+p,C=U2FsdGVkX1+jhXvU0k+fSNQrD5fAPzT27tvTCjQlS1DLSQl1XocaAL0tgD4/Sw+ROaMKU3t07y+qauFtNe9s0Sedqiexsiz2Lgvgr4cwpoJqnBlVKd8h7U5VQbHTc65k
X-Complaints-To: abuse@xs4all.nl
 by: Peter van Hooft - Mon, 31 Jan 2022 13:02 UTC

On 2022-01-31, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>
> I've hit an interesting problem. This is on fdbsd13/arm64/rpi4, and
> there's something amiss with char to int conversions. Or at least, a
> difference from i386.
>
>
> The immediate symptom is that spfmilter won't start - just says
> 'unrecognised option', with a seemingly empty string appended that's
> actually 0xFF.
>
> This comes from the getopt() loop, whose guts are
>
> char c;
> while ( ( c = getopt_long( argc, argv, shortopts, longopts, &idx ) ) !=
> -1 ) {
> .....

Different default for -funsigned-char and -fsigned-char ?

peter

Re: arm64 char conversion issue

<slrnsvfoqb.2jvm.naddy@lorvorc.mips.inka.de>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=139&group=comp.unix.bsd.freebsd.misc#139

  copy link   Newsgroups: comp.unix.bsd.freebsd.misc
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.szaf.org!inka.de!mips.inka.de!.POSTED.localhost!not-for-mail
From: nad...@mips.inka.de (Christian Weisgerber)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: arm64 char conversion issue
Date: Mon, 31 Jan 2022 13:25:31 -0000 (UTC)
Message-ID: <slrnsvfoqb.2jvm.naddy@lorvorc.mips.inka.de>
References: <st8f2h$bk8$1@dont-email.me>
Injection-Date: Mon, 31 Jan 2022 13:25:31 -0000 (UTC)
Injection-Info: lorvorc.mips.inka.de; posting-host="localhost:::1";
logging-data="86007"; mail-complaints-to="usenet@mips.inka.de"
User-Agent: slrn/1.0.3 (FreeBSD)
 by: Christian Weisgerber - Mon, 31 Jan 2022 13:25 UTC

On 2022-01-31, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

> I've hit an interesting problem. This is on fdbsd13/arm64/rpi4, and
> there's something amiss with char to int conversions. Or at least, a
> difference from i386.

On arm64, plain "char" is "unsigned char". On x86 it's "signed char".

> char c;
> while ( ( c = getopt_long( argc, argv, shortopts, longopts, &idx ) ) !=
> -1 ) {

That's broken code. It must be "int c". Only an int will capture
all possible char values and additionally -1.

The prototypical example is this:

while ((c = getchar()) != EOF) { /* EOF is -1 */
...
}

With "char c" this is broken for both platforms:
* On arm64 it's an infinite loop.
* On x86 it will prematurely terminate when it encounters a byte
with the value 0xff.

Any variable that is intended to hold any character plus EOF _must_
be declared int. This is basic C.

Most architectures default to signed char. Notably arm and powerpc,
in their 32 and 64-bit incarnations, default to unsigned.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

(resolved) Re: arm64 char conversion issue

<st8psj$e6e$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=140&group=comp.unix.bsd.freebsd.misc#140

  copy link   Newsgroups: comp.unix.bsd.freebsd.misc
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: usenet...@scottsonline.org.uk.invalid (Mike Scott)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: (resolved) Re: arm64 char conversion issue
Date: Mon, 31 Jan 2022 13:57:39 +0000
Organization: Scott family
Lines: 48
Message-ID: <st8psj$e6e$1@dont-email.me>
References: <st8f2h$bk8$1@dont-email.me>
<slrnsvfoqb.2jvm.naddy@lorvorc.mips.inka.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 31 Jan 2022 13:57:39 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8184df9da746037f13acfef0feb7add9";
logging-data="14542"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19qg3fqMQrnFkEcOUG1UrsgQx/sYmHN0Z0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Cancel-Lock: sha1:cU72k52E8VEyTWN0lQPhtIpIye0=
In-Reply-To: <slrnsvfoqb.2jvm.naddy@lorvorc.mips.inka.de>
Content-Language: en-GB
 by: Mike Scott - Mon, 31 Jan 2022 13:57 UTC

On 31/01/2022 13:25, Christian Weisgerber wrote:
> On 2022-01-31, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>
>> I've hit an interesting problem. This is on fdbsd13/arm64/rpi4, and
>> there's something amiss with char to int conversions. Or at least, a
>> difference from i386.
>
> On arm64, plain "char" is "unsigned char". On x86 it's "signed char".
>
>> char c;
>> while ( ( c = getopt_long( argc, argv, shortopts, longopts, &idx ) ) !=
>> -1 ) {
>
> That's broken code. It must be "int c". Only an int will capture
> all possible char values and additionally -1.
>
> The prototypical example is this:
>
> while ((c = getchar()) != EOF) { /* EOF is -1 */
> ...
> }
>
> With "char c" this is broken for both platforms:
> * On arm64 it's an infinite loop.
> * On x86 it will prematurely terminate when it encounters a byte
> with the value 0xff.
>
> Any variable that is intended to hold any character plus EOF _must_
> be declared int. This is basic C.
>
> Most architectures default to signed char. Notably arm and powerpc,
> in their 32 and 64-bit incarnations, default to unsigned.
>

OK, thanks. I'll contact the program's author and suggest a patch is in
order. Worrying that no-one on the fbsd team seems have to tried running
the code though.

I wonder how many things like this are lurking. Lucky this one gave an
immediate and obvious error.

Oh, and thanks for pointing out the differing defaults on the two platforms.

--
Mike Scott
Harlow, England


devel / comp.unix.bsd.freebsd.misc / (resolved) Re: arm64 char conversion issue

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor