This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/3] explicit_bzero v5


On 11/15/2016 04:11 PM, Richard Henderson wrote:
> On 11/15/2016 04:55 PM, Zack Weinberg wrote:
>> I wasn't able to find anything definitive about when GLIBC_PRIVATE
>> should be used.
> 
> Between .so libraries of glibc's implementation, as such symbols are
> (wait for it) private and are allowed to change at will between releases.

This doesn't fully resolve the question in my head, though.  The case
we're discussing is an impl-namespace symbol __explicit_bzero, which is
functionally identical to a public symbol explicit_bzero, and not
expected ever to change its behavior.  It exists, as far as I
understand, _solely_ so that uses of this symbol in libcrypt.so will
resolve to the definition in libc.so even if other objects in the link
interpose on the public symbol.  Other symbols that exist for the same
reason have been given both GLIBC_2.xx versions (e.g. __bzero,
__strtok_r, __clone, __connect, __send) and GLIBC_PRIVATE versions
(__getrlimit, __madvise, __recv, __socket) so I don't know what is
considered to be the Right Thing.

(If I were to make the public declaration in string.h redirect to
__explicit_bzero, then clearly it ought to be a GLIBC_2.xx export rather
than a GLIBC_PRIVATE export.  But, as I'll go into more elsewhere, I'm
not convinced that's actually a good idea.)

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]