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

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

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

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