Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context

On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker <jilles at stack.nl> wrote:

> On Tue, Sep 11, 2018 at 08:48:03AM -0700, Mark Millard wrote:
>> [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones.
>> lib/libc/string/memcmp_test:diff is one of them.]
> 
>> ===> Broken tests
>> lib/libc/string/memcmp_test:diff  ->  broken: Premature exit; test case received signal 6 (core dumped)  [3.962s]
> 
> The problem here is that our definition of memcmp() is tighter than the
> one in the standards and glibc. We define the return value to be the
> difference between the first differing bytes, while the standards and
> glibc only define the sign (negative, zero or positive).
> 
> Looking at contrib/cortex-strings/src/aarch64/memcmp.S, a
> bic pos, pos, #7  after the clz may help.
> 
> On another note, the comment just below that,
> 
>        /* But we need to zero-extend (char is unsigned) the value and then
>           perform a signed 32-bit subtraction.  */
> 
> shows a wrong reason for doing the right thing since memcmp (as well as
> strcmp and strncmp) are defined to compare based on unsigned chars,
> regardless of the signedness of char.

Ahh, standard are so much fun: there are so many to choose from.

I looked up ISO/IEC 9899:2011 (E) and its 7.24.4.1 "The memcmp function".
It makes no such explicit claim about using using unsigned chars for
the comparison standard:

QUOTE of the Description part:
The memcmp function compares the first n characters of the object pointed
by s1 to the first n characters of the object pointed by s2.
END QUOTE

QUOTE of the Returns part:
The memcmp function returns an integer greater than, equal to, or less than zero,
accordingly as the object pointed to by s1 is greater than, equal to, or less than
the object pointed to by s2.
END QUOTE

If I had to guess the intent of "characters" would be based on the char type
for C11. I did not find anything about the issue in the C99 rationale that I
also happen to have available to look at.

For all I know, POSIX or other standards may be more explicit and not
agree.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)