Namespaces and inter-library private symbols

[Ken Raeburn]

On Nov 13, 2009, at 11:43, Nicolas Williams wrote:
> If you don't declare them in public/installed/shipped headers, then  
> they
> can only be used by folks who are willing to dig into the source to  
> find
> declarations.  If you don't export them then they can't be used  
> period.

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  
> you
> 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.

Ken