Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char

On Sep 10, 2023, at 05:58, Mike Karels <mike@karels.net> wrote:

> On 10 Sep 2023, at 2:31, Mark Millard wrote:
> 
>> kyua tests that use the:
>> 
>> /usr/tests/sys/cddl/zfs/bin/mkfile
>> 
>> program like so (for example):
>> 
>> mkfile 500M /testpool.1861/bigfile.0
>> 
>> (which should be valid) end up with mkfile
>> instead reporting:
>> 
>> Standard error:
>> Usage: mkfile [-nv] <size>[e|p|t|g|m|k|b] <filename> ...
>> 
>> which prevent the kyua test involved from working.
>> 
>> Turns out this is from expecting char to be always
>> signed (so a -1 vs. 255 distinction, here in an
>> aarch64 context):
>> 
>> . . .
>> (gdb) list
>> 179 /* Options. */
>> 180 while ((ch = getopt(argc, argv, "nv")) != -1) {
>> 181 switch (ch) {
>> 182 case 'n':
>> 183 nofill = 1;
>> 184 break;
>> 185 case 'v':
>> (gdb) print ch
>> $16 = 255 '\377'
>> (gdb) print/x -1
>> $17 = 0xffffffff
>> (gdb) print/x ch
>> $18 = 0xff
>> . . .
>> 
>> With the mix of unsigned and signed it ends up
>> being a 0xffu != 0xffffffffu test, which is
>> always true.
> 
> mkfile is broken.  getopt returns an int, and -1 on end.
> It never returns 0xff.  But mkfile declares ch as char,
> which truncates the return value -1.  ch is a bad (misleading)
> variable name, although getopt(3) uses it as well (but declared
> as int).

Yep: for char being signed, the code is still wrong
via the char ch use. But the observed behavior is
very different than for char being used but being
unsigned. In this context, consequences of the
unsigned char behavioral results are observable in
the kyua run results but went unnoticed.

I used to run into examples of the use of unsigned
char for holding the getopt result back in my powerpc
days as well and dealt with upstreams for a port or 2
for getting it fixed after finding such was the source
of odd behavior I'd observed. If I remember right,
this is the first example of running into the specific
issue in my aarch64 and armv7 time frame.

> Mike
> 
>> So the switch is reached as if a "-" prefix was
>> present (that is not). Then the "option" is classified
>> as invalid and the usage message is produced.
>> 
>> Apparently no one had noticed. That, in turn, suggests a
>> lack of inspected testing on aarch64, powerpc64,
>> powerpc64le, armv7, powerpc, and powerpcspe. That, in
>> turn, suggests that kyua test inspection for the likes
>> of aarch64 is not historically a part of the release
>> process for openzfs or for operating systems that include
>> openzfs.
> 


===
Mark Millard
marklmi at yahoo.com