Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Sep 2021 18:17:17 -0400
From: Chris Kennelly <>
Cc: GNU C Library <>,
Subject: Re: Add new ABI '__memcmpeq()' to libc

On Thu, Sep 16, 2021 at 5:50 PM enh <> wrote:

> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().

llvm-libc's implementation only returns the boolean, though.

The mem* functions are extremely sensitive to instruction cache effects, so
having 3 unique implementations (__memcmpeq, bcmp, memcmp) that do similar,
but subtly different things can be a hidden performance cost--one that is
hard to demonstrate with a microbenchmark.  Our experience developing
optimized mem* routines ended up showing better performance in actual
applications when we accepted seemingly worse microbenchmark performance by
optimizing for code footprint instead (more extensive notes for mem* in
memcmp specifically (section 4.4)

The alternative would be to alias (as the NOTES suggest as a possible
implementation), but I think that raises James' question of why not just
use bcmp?  Dependencies on non-boolean implementations of bcmp seem
rare--namely, I haven't actually seen one.

> On Thu, Sep 16, 2021 at 2:43 PM Joseph Myers <>
> 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.
>> --
>> Joseph S. Myers

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.