* Richard Biener via Gcc: > 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 do not think ELF provides that capability. We can add a declaration to <string.h> to communicate the availability. I think this is how glibc (and other libcs) communicate the availability of non-standard interfaces to GCC. > (I'm not sure whether a GCC build-time decision via configure is the > very best idea) If libstdc++ or libgcc_s have a symbol dependency on glibc 2.35 for other (unrelated) reasons, would the build-time dependency be less of a concern? Because another such dependency exists? Thanks, Florian
