Patches: improve innconf.h, remove obsolete docs
rra at stanford.edu
Sun Feb 24 18:29:27 UTC 2013
Richard Kettlewell <rjk at terraraq.org.uk> writes:
> Taking the same thought a bit further: these headers are pretty free in
> their use of namespace. For instance, xmalloc is very likely to clash
> with a symbol of similar meaning (but not necessarily an identical one)
> in any nontrivial program. Would a patch to improve this be likely to
> be accepted?
Stuff like xmalloc really shouldn't be publicly exposed from libinn at
all. I'd rather see that change than to play games with namespace. To
see the structure that what started as INN's portability layer turned
into, see rra-c-util at:
or one of my other projects. This is something that I've kind of wanted
to convert INN to, but haven't had the time. :/
Basically, the bits of libinn that aren't actually useful for clients (and
hence don't have a proper namespace) should move to a libportable or
libutil, which are only used internally by INN and not externally. That
would include all the memory allocation routines and quite a lot of other
stuff. I'm not sure there's really much of libinn that's actually useful
to expose as a shared library other than the nntp routines and innconf,
and maybe confparse, all of which already have proper namespaces. Maybe
inndcomm.h (although it could use some renaming and cleanup first). And
the paths.h header, but there's no actual code behind it.
> What I have in mind is:
> (1) All publicly visible symbols renamed to start inn_
> (or INN_ for things already all upper-case).
This will make it basically impossible to ever merge the current utility
functions with newer versions of the same code from rra-c-util, which
would be unfortunate. That stuff is really intended as a general C
infrastructure layer, which should be split out and used only by the
internal INN code but keep generic names.
> (5) Build the INN libraries as a shared library (or as a collection of
> shared libraries). I can see that this might be more controversial,
> as it would more caution about interface changes than INN has
> presumably required in the past.
Note that this is already done now by default. libinnstorage and
libinnhist aren't in too bad of shape. It's really only libinn that has
lots of interface problems.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers