Config parsing (4/4): Proposed starting interface

[Russ Allbery]

Aidan Cully <aidan at panix.com> writes:

> How does one verify syntax using this API?  E.g., make sure that the
> user didn't stick some garbage parameter name into the file?

I was going to tag that as one of the things I hadn't made a decision on
yet and then forgot.  Thanks for pointing that out.

The main problem with finding a good way to do this is knowing what
parameters are allowed in convenience groups, the group { } groups
surrounding a bunch of groups that the client cares about that are only
there to set some default values.  You can't really know what parameters
are valid for such a group without knowing what groups it contains.

Other than that, the fairly obvious interface (to me at least) is to add
something like:

  struct vector *conf_params(config_group);

that returns a vector of parameter names that are set in that group.  The
caller can then compare that against a list of valid parameters, and also
try calling config_param_<type> for each one with the expected type to
make sure that succeeds.

One solution that I thought of was to just return a vector that contains
all the parameters that are set, including all of the inherited ones.  One
drawback is that that could be slower, but I don't think we care too much
there; full verification can be slow.  Another drawback is that it could
mean reporting errors more than once if the error is in a parameter
inherited by a bunch of groups.

Oh, the other thing that is probably needed for verification purposes is
to modify:

>> /* config_find_group returns the first group of the given type found in the
>>    tree rooted at its argument.  config_next_group returns the next group in
>>    the tree of the same type as the given group (or NULL if none is found).
>>    This can be used to do such things as enumerate all "peer" groups in a
>>    configuration file. */
>> config_group config_find_group(config_group, const char *type);
>> config_group config_next_group(config_group);

one of these slightly or add another similar interface to allow you to
iterate through all of the groups, regardless of type.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>