New configuration parser ready

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:
> On Tue, 3 Sep 2002, Russ Allbery wrote:

>> [ making sure that there are no unrecognized keys in the inn.conf file ]

>> Well, part of the problem is that the code isn't entirely written yet to
>> obtain all of the keys used in a configuration block.  But that should be
>> easy to fix.  (It's already stubbed in; I just haven't written it yet
>> because I didn't need it for the first round of things.)

> Ah.  (What's the interface to that look like?)

That part's stubbed in include/inn/confparse.h:

/* Used for checking a configuration file, returns a vector of all parameters
   set for the given config_group, including inherited ones. */
struct vector *config_params(struct config_group *);

> Ah, sure.

> It think I need to see what the interface to the entire generic parser
> is before I can really say anything useful.  So I'll just hold off until
> the commit.

Well, the generic parser is in there (include/inn/confparse.h), just the
additional code for inn.conf isn't there yet.  (Which includes code that
will eventually be made generic for taking the results of a configuration
file parse and turning it into a struct.)

> Doing it outside though, potentially the easiest thing is to enumerate
> all of the values in both sets, each into an array of strings, sort both
> arrays, and do a single pass (like a merge from mergesort but without
> actually bothering to merge them) in linear time checking if any keys
> are missing, duplicated, or unknown (if the parser doesn't catch unknown
> keys at an earlier point).  It's still total n log n, which is I believe
> the best you can do without using a hash table.

Note that if you have an already-sorted list of valid parameters (and that
list can just be maintained in the source file in sorted order, once we
don't have maintenance reasons for separating it out into sections),
finding each parameter is a binary search, so with a linear scan of all of
the parameters that were actually set, you get O(n lg n) already.  So it's
probably not worth the additional complexity of sorting the keys that were
actually given.

I'm now running the new inn.conf parsing code on headwall and after fixing
a few more nits with what Bourne shell expects, I think it's working
properly.  So I'm going to start committing it either later tonight or
tomorrow.

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