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