Configuration parser and integers

[Julien ÉLIE]

Hi Russ,

>> The configuration parser defines numbers:
>>    integer = ["-"] 1*DIGIT
>> but a lot of them must be positive.
>
>> Should we do something about that at the level of the parser?
>> (defining a positive integer?)
>
> 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?

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?

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.


Is that the right thing to do?

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?



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!

-- 
Julien ÉLIE

« Maior e longinquo reuerentia. » (Tacite)