[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