From owner-freebsd-current@freebsd.org Sun Sep 16 20:21:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05C8B10A9736 for ; Sun, 16 Sep 2018 20:21:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A14BD7EAA4 for ; Sun, 16 Sep 2018 20:21:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: JSOFQo4VM1mYQcBz.40qWfs251XMRE0ME4h1gaAt.KnD1kpEn36wMCwmlZj7blv qIliHFSA6Baernz4IMSOLFiS3RxS.HMRGE6GXnF8zy7s0X9amV7Krggminoxtq74IljZXnDBvCZW 46BM2SH26OUxfHWOC_KgX8BtZzcKfD8q_IulXafdZO_sHFVzFRYU5plrY9KvRzDjGD22uPaVWE8P OISLMrng2lxiv5WSYdh.1iIWtbXQw.tIl_gFXaDHbpCfxUlaFZWmGa9KXpymjqD8PJC8_O2b5n6d sFUdqgpAEa6jrrX0pEFdYyDCpSxw0eEBJHhpZ786.p0COVMej9s7umBWCuOzzjGSR3YKkJkzPnWH iT8LHBODza7PqG2tm9GG83XGILjJc4H9JbYt17JzeQMLuTK2efZKpy2arYqQ7sDrmKJVAdBP4k7d 92_DJ5WdrE0Jzjz8gMGVwas_w5Oc7qtgqclHXiR1IEcAJDLkDQa48nyROz8EtbzOHWn2F0CR7H2y 3eyVUqiLZAVp_7h4nlj1pNEvyO40pXfnax4U2lO4y9OVmcj2Y8rRLNBcLoaR0H92n.w2yutskU2u YZc_l7qX9R9HdgJnMsNUm_xz9AURFSstwESy3g1epxxxHvs_9n08N0.v9U7cdTLCWlOxSd4a7i7P j_DMc.eZN35iizgIIYEO6_oA5_Jx5b2nR3Q5npSRrdBpnspGlGh1.4KN0ddV7NLT.M5.PdOLMXNn OFkfmY84vG6BKV_WfiBnEGeNrAahVA9mrKXb3dlVmmQnto2BXpj1r6L6L6pszym5hWq9Rive6KGX bWI8hN9FF9fckho_dRpo9EanvWdTXFefrpo4JcwsXYdum7.qyJnqc8bW.EI.gherKENtov6Lt8N2 zLTvdpwkvNLLa5ixpSUTZKg8aQPi.HtcISjn4sGHl4FKpif4fQIbZb80z6ZKZRVRM0P4bpCmYDQw D9Uqxdb8VxpnYn8QXAjbopn7ZimhWEtPRcw_xGnOBY7LhJMp7LKebzPF9l68OPtS6dUM7Ko79u2G sJzrN0RITexM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Sun, 16 Sep 2018 20:21:38 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 52cbd135864599ae043a5a6370b2329a; Sun, 16 Sep 2018 20:21:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context From: Mark Millard In-Reply-To: <20180916175029.GA55717@stack.nl> Date: Sun, 16 Sep 2018 13:21:33 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180916175029.GA55717@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2018 20:21:45 -0000 On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker 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)