Namespaces and inter-library private symbols

[Greg Hudson]

On Tue, 2009-11-10 at 16:48 -0500, Nicolas Williams wrote:
> Vendors should just not ship k5-int.h and that's that.  Developers
> should have enough warning from the fact that they cannot find C
> prototype declarations for functions that they think might be useful to
> them but which ware internal.

Jeff Altman wrote:
> Symbols that are exported by libraries are inevitably used even when
> they are declared private.  The only way to ensure that third parties
> do not place dependencies on a function is to not export it.

So, those are the two extremes.  I think if we name a function
krb5int_foo, that's a pretty clear indication that it's not part of the
stable API or ABI.  Adding an extra layer of hassle (such as the
accessor) isn't going to stop a truly determined application writer from
using internal functionality.

Merely failing to prototype a function in krb5.h is not, in my opinion,
a clear indication.  It also runs afoul of autoconf tests for functions
entering the public API in later versions of krb5.  For instance, Luke
chose not to make krb5_get_credentials_for_proxy part of the public API
for 1.8 so that we can retain the freedom to change it.  But suppose we
change the function signature and then make it part of the public API in
1.9.  How can an application tell whether krb5_get_credentials_for_proxy
is available in the API of the libkrb5 it is building against?  The
usual AC_CHECK_FUNC autoconf test will find the symbol in krb5 1.8, even
though it's not part of that version's API.

I am awaiting clarification on an offlist comment about the accessor,
and I'll probably bring this up again with the MIT staff, but my
expectation is that we will standardize on using exported symbols with
the krb5int_ prefix for tree-internal inter-library functions.

Nico wrote:
> I recommend that you concentrate efforts on actual, useful features
> and bug fixes over mass symbol rename excercises.

For the moment, I'm just interested in standardizing a practice for
future work, although it's possible we will rename some newer non-public
krb5_ symbols to krb5int_ to avoid the autoconf problem described above.