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

Jilles Tjoelker jilles at stack.nl
Sun Sep 16 20:50:32 UTC 2018


On Sun, Sep 16, 2018 at 01:21:33PM -0700, Mark Millard wrote:
> On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker <jilles at stack.nl> wrote:

> > 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.

In C99, C11 and C17, the text about using unsigned chars is under
"Comparison functions" and it applies to memcmp, strcmp and strncmp
(which are documented together in the section).

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

POSIX does not document memcmp, strcmp and strncmp close together and
copies the text about using unsigned chars to each of them. This means
that it agrees with the C standards.

-- 
Jilles Tjoelker


More information about the freebsd-current mailing list