[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Sep 2021 21:36:15 -0400
From: James Y Knight <jyknight@...gle.com>
To: libc-coord@...ts.openwall.com
Cc: GNU C Library <libc-alpha@...rceware.org>, gcc@....gnu.org
Subject: Re: Add new ABI '__memcmpeq()' to libc
On Thu, Sep 16, 2021 at 5:50 PM enh <enh@...gle.com> wrote:
> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().
>
Per spec, bcmp is not a three-way comparison, it is an equality comparison
with exactly the same semantics as proposed for __memcmpeq.
Glibc currently implements bcmp as an alias to memcmp -- which is valid,
but provides more than just the boolean equality semantics. There was
concern raised that modifying that might break existing binaries. However,
this concern can be easily addressed in the same way glibc typically
addresses such compatibility concerns: creating a new symbol-version for
the new bcmp implementation, with the previous bcmp symbol-version
remaining as a memcmp alias.
> On Thu, Sep 16, 2021 at 2:43 PM Joseph Myers <joseph@...esourcery.com>
> wrote:
>
>> On Thu, 16 Sep 2021, James Y Knight wrote:
>>
>> > Wouldn't it be far simpler to just un-deprecate bcmp?
>>
>> The aim is to have something to which calls can be generated in all
>> standards modes. bcmp has never been part of ISO C; there's nothing to
>> undeprecate there.
>
>
OK, I can see that. I suppose that strict ISO C compatibility could be
important to someone. :)
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
