Patches: improve innconf.h, remove obsolete docs

Richard Kettlewell rjk at terraraq.org.uk
Sun Feb 24 11:36:55 UTC 2013


On 23/02/13 22:52, Russ Allbery wrote:
> Richard Kettlewell <rjk at terraraq.org.uk> writes:

>> Attached are a couple of suggested patches to INN to improve the
>> experience of external programs that use /usr/include/inn and
>> /usr/lib/libinn.a.
>
>> HAVE_SSL.diff makes the layout of the innconf structure independent of
>> INN's build options.  External programs have no idea how INN was built and
>> it's (at best) tedious for them to have to work it out.
>
>> HeaderFind.diff removes some long-obsolete documentation.
>
> Thanks, applied.

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?

What I have in mind is:

(1) All publicly visible symbols renamed to start inn_
     (or INN_ for things already all upper-case).
(2) A collection of #defines to provide the same symbols as now.
(3) An INN_COMPATIBLE_NAMESPACE define.  If set to 1 the #defines
     in (2) are enabled, if set to 0 they are disabled.
     The default value for INN_COMPATIBLE_NAMESPACE is 1.
(4) Some kind of build-time test to detect future namespace
     leakage.  (This might be limited to easy platforms, but
     it only actually needs to work on popular platforms to
     achieve the desired effect.)

(2) and (3) mean that existing code, including the bulk of INN, requires 
no change.

And maybe:

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

ttfn/rjk



More information about the inn-workers mailing list