Namespaces and inter-library private symbols
raeburn at MIT.EDU
Fri Nov 13 13:24:07 EST 2009
On Nov 13, 2009, at 11:43, Nicolas Williams wrote:
> If you don't declare them in public/installed/shipped headers, then
> can only be used by folks who are willing to dig into the source to
> declarations. If you don't export them then they can't be used
There are still C compilers that will silently assume an int-returning
function of unspecified arguments, if it hasn't seen a declaration.
If after looking at some of our sources to see how something was done,
someone tries adding a call to their code and it compiles, they may
not think about it any further.
On the other hand, an interface that requires the use of a structure
that's not in the installed headers, that's a somewhat bigger stick to
beat them over the head with. If they are using our sources, they can
grab the internal headers, but they know (better) that they're doing it.
> Are there symbols which must be exported but aren't public? (What we
> might call "consolidation private" or "contracted private" in the Sun
> world of development). If not, then I strongly recommend Jeff's
> proposal. If there are, can you remove or promote them all so that
> only have libkrb5-private and public interfaces only?
I think there are things we're doing that we want to use in multiple
places internally, but don't want to be stuck maintaining indefinitely
for random programs that ought not to be messing around with such
things. For example, the "send a message to service X in realm Y and
wait for a response" code, or the wrappers around mutexes, or our
getaddrinfo wrapper. Or anything that lets us peek at internal state
for debugging, printing values for test vectors, etc.
More information about the krbdev