On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers <jos...@codesourcery.com> wrote: > > On Thu, 16 Sep 2021, Chris Kennelly wrote: > > > In terms of relying on the feature: If __memcmpeq is ever exposed as an a > > simple alias for memcmp (since the notes mention that it's a valid > > implementation), does that open up the possibility of depending on the > > bcmp-like behavior that we were trying to escape? > > The proposal is as an ABI only (compilers would generate calls to > __memcmpeq from boolean uses of memcmp, users wouldn't write calls to > __memcmpeq directly, __memcmpeq wouldn't be declared in installed libc > headers). If such dependence arises, that would suggest a compiler bug > wrongly generating such calls for non-boolean memcmp uses.
So the compiler would emit a call to __memcmpeq and at the same time emit a weak alias of __memcmpeq to memcmp so the program links when the libc version targeted does not provide __memcmpeq? Or would glibc through <string.h> magically communicate the availability of the new ABI without actually declaring the function? (I'm not sure whether a GCC build-time decision via configure is the very best idea) Richard. > -- > Joseph S. Myers > jos...@codesourcery.com
