This is the mail archive of the
mailing list for the glibc project.
Re: Special symbol version for glibc's internal interfaces
- To: Philip Blundell <pb at nexus dot co dot uk>
- Subject: Re: Special symbol version for glibc's internal interfaces
- From: Andreas Jaeger <aj at suse dot de>
- Date: Tue, 28 Aug 2001 16:09:56 +0200
- Cc: libc-alpha at sources dot redhat dot com, Karl dot Runge at Sun dot COM
- References: <firstname.lastname@example.org><E15bjRJ-0004MLemail@example.com>
Philip Blundell <firstname.lastname@example.org> writes:
>>Hiding those symbols with GLIBC_PRIVATE would make it explicit that
>>those are internal interfaces.
>>Why didn't we follow this at first when adding symbol versioning to
>>glibc? What do other think about this?
> What does that really buy you? People can still link to the symbols if they
> are determined, whatever version you give them. The presence of the two
> leading underscores ought to be sufficient to warn people that these are an
> internal interface.
The two advantages I see directly are:
- psychological, you see that a program is using internal symbols
directly. We can much easier tell people that they're using
internal symbols. The two underscores is not always correct, some
inline functions/macros that are public use them.
- Tools can be easily implemented that check whether objects use these
symbols, we don't need to maintain a database of internal functions.
Have a look at the following RPM output:
$ rpm -q --requires bash
A GLIBC_PRIVATE would stick out and alarm people.
> That said, I don't think your proposal will do any harm either.
SuSE Labs email@example.com