Date: Sun, 16 Sep 2018 13:21:33 -0700 From: Mark Millard <marklmi@yahoo.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Message-ID: <D8F59B15-20C1-4159-898A-C8EE506A0299@yahoo.com> In-Reply-To: <20180916175029.GA55717@stack.nl> References: <C7047A90-89C6-4CB9-A1F2-339A6E1256A4@yahoo.com> <CF050D05-FA7A-4AA8-8013-90EC1293F76C@yahoo.com> <20180916175029.GA55717@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.] >=20 >> =3D=3D=3D> Broken tests >> lib/libc/string/memcmp_test:diff -> broken: Premature exit; test = case received signal 6 (core dumped) [3.962s] >=20 > 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). >=20 > Looking at contrib/cortex-strings/src/aarch64/memcmp.S, a > bic pos, pos, #7 after the clz may help. >=20 > On another note, the comment just below that, >=20 > /* But we need to zero-extend (char is unsigned) the value and = then > perform a signed 32-bit subtraction. */ >=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8F59B15-20C1-4159-898A-C8EE506A0299>