[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <455bbaab-5ed3-fa1d-cf51-1b0a644c858d@gmail.com>
Date: Fri, 17 Sep 2021 10:55:38 -0600
From: Martin Sebor <msebor@...il.com>
To: Jakub Jelinek <jakub@...hat.com>, Florian Weimer <fweimer@...hat.com>
Cc: Richard Biener via Gcc <gcc@....gnu.org>,
GNU C Library <libc-alpha@...rceware.org>,
Joseph Myers <joseph@...esourcery.com>, libc-coord@...ts.openwall.com
Subject: Re: Add new ABI '__memcmpeq()' to libc
On 9/17/21 3:12 AM, Jakub Jelinek via Gcc wrote:
> On Fri, Sep 17, 2021 at 10:08:34AM +0200, Florian Weimer via Gcc wrote:
>>> 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.
>
> Yeah, that is what we've done in the past, e.g. in case of stpcpy.
The stpcpy hack has been a cause of mysterious bugs as discussed
in pr82429. It means that programs that declare standard functions
without #including <string.h> or use GCC built-ins directly are
enalized by ending up with suboptimal code than those that do
include the header.
It's also a subtlety that not all of us keep in mind when working
on GCC, that can lead to wasted time trying to understand why
an expected optimization isn't working in one test case when it
does work in an apparently equivalent one.
Martin
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.
