[PATCH RFC v2 0/8] termios: support arbitrary baud rates on Linux, minor cleanups, proposed alternative interface
H. Peter Anvin
hpa@zytor.com
Mon Apr 28 23:14:23 GMT 2025
So if I read you correctly, it might be redundant but should be OK to
use double-underscore symbols everywhere?
On 4/28/25 10:41, Joseph Myers wrote:
> On Fri, 25 Apr 2025, H. Peter Anvin wrote:
>
>> 2. When to use __foo() functions. In my patches I have assumed that
>> calls internal to glibc.so should be using __foo() not foo(), but I
>> got a very muddy reply as to "when things cross namespace
>> boundaries", pointing me to a document which brought absolutely no
>> clarity to the issue.
>
> There are two separate but sometimes linked issues:
>
> * Namespace issues (mainly for static linking): if e.g. an ISO C function
> calls a POSIX one (directly or indirectly), the call needs to use a name
> __* in the implementation namespace. The linknamespace tests should
> detect violations of this for the standards that they cover. This issue
> does not apply if the function being called is in all the standards that
> contain the caller.
>
> * PLT avoidance: internal calls within libc.so should not be interposable,
> meaning they should use a function name not exported from the library.
> This can be achieved via libc_hidden_proto / libc_hidden_def which result
> in a hidden alias being used for the calls; if an internal name __* that's
> not exported is used, those aren't needed (although they are often used
> for such names as well) - but in that case, if not using libc_hidden_*,
> the internal name should preferably be declared with attribute_hidden
> (since sometimes it's beneficial for code generation for it to be visible
> at compile time, not just link time, that the call is to a non-exported
> name).
>
More information about the Libc-alpha
mailing list