Configuration parser and integers

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

>> We could, but as you can see from lib/innconf.c, defining additional
>> data types at the level of the configuration syntax is a little
>> annoying, since it expands the union and requires new cases and macros.
>> It might be the best and most robust approach, though, since it would
>> make it easy to catch all of them without adding a bunch more
>> validation.

> Therefore defining TYPE_SIGNED_NUMBER (long) and TYPE_UNSIGNED_NUMBER
> (unsigned long) instead of TYPE_NUMBER in lib/innconf.c and adding the
> relevant used functions?

Yeah, exactly, although I'd probably use TYPE_UNUMBER instead just to keep
things brief.

> And also have config_param_signed_number() and
> config_param_unsigned_number() instead of config_param_integer() in
> lib/confparse.c, so that the function returns a warning if "-" is found
> at the beginning of the value to parse?

Yup, and those names sound reasonable to me.

> Which also means that innconf->xxx values will be unsigned (instead of
> being signed).  Maybe a few casts will be needed (or no longer
> necessary) in comparisons and printf() calls.

Indeed.

> Is that the right thing to do?

I think so.  It's a fair bit of work, but it's the best way to get
comprehensive error checking.

> Or did you mean not to change lib/confparse.c and keep signed numbers
> in the code, only checking for those which are mentioned to be unsigned
> whether they are >= 0 in lib/innconf.c, just after they have been parsed?

We could do that, and it would be simpler, but I suspect we'll do better
in the long run by doing the work of putting them into the language.

> Hmm...  I am under the impression that all the numeric inn.conf parameters
> currently require a positive value.
> Even rlimitnofile could be set to 0 if it should not be limited.
> nice(1) values for nnrpd are also expected to be positive in the code.
> So in fact, nisi fallor, only unsigned numbers will be used after the patch!

Hm, that makes it tempting to just redefine numbers as unsigned and add
signed numbers later if they're really required.

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