New configuration parser ready

[Russ Allbery]

Katsuhiro Kondou <Katsuhiro_Kondou at isc.org> writes:
> Russ Allbery <rra at stanford.edu> wrote;

>> Does this sound reasonable to everyone?

> It's ok to me.  One more feature to be included, I hope, is to examine
> characters to be used for specific parameters like pathhost.  I've seen
> path which includs white spaces many times.

There will be hooks to do this, definitely.  It can either be done in the
routine that runs every time the inn.conf file is parsed to check for
things like ovmethod being set, or I plan on adding an additional
verification function to replace the current inncheck code that works off
the same parsing tables and checks things like making sure that there are
no unrecognized keys in the inn.conf file.  (This is a somewhat slow
operation, so I don't think it's necessary to do every time inn.conf is
loaded, but it could be done there if we wanted.)

The new code is ready for committing, I think, but I want to install it on
headwall first to make sure I caught everything obvious.  I expect there
will be some minor instability and shakeout afterwards, since I basically
touched everything in the source tree.  I'm hoping to get to that today or
tomorrow, and will then commit the grand switchover.

Incidentally, I dropped the -c and -f options to innconfval during the
upgrade.  -c was to print out csh-quoted variable settings; since we
dropped innshellvars.csh a long time ago with nary a peep, I don't expect
this to be an issue.  -f said to always use the value direct from the
inn.conf file rather than using any default, which is really difficult to
implement with the new parser and also doesn't seem to have any real
advantages over just using grep since it was mainly used for debugging.  I
checked, and neither of these options are used anywhere in INN.

Overall, there was a net increase of around 120 lines of actual code
between the two parsers.  For those who are curious, here's the statistics
on the old inn.conf parser:

  1047   619   |lib/getconfig.c
   170    80   |frontends/innconfval.c
   364     6   |include/innconf.h
----------------
  1581   705    total lines/statements

    60  lines had comments         3.8 %
     6  comments are inline       -0.4 %
    46  lines were blank           2.9 %
   256  lines for preprocessor    16.2 %
  1225  lines containing code     77.5 %
  1581  total lines              100.0 %

  1288  comment-chars              2.4 %
   230  nontext-comment-chars      0.4 %
 10324  whitespace-chars          19.2 %
  8074  preprocessor-chars        15.0 %
 33922  statement-chars           63.0 %
 53838  total characters         100.0 %

  4426  tokens, average length 7.39

  0.03  ratio of comment:code

    23  top-level blocks/statements
     6  maximum blocklevel
  3.69  ratio of blocklevel:code

and the new parser:

  1163   429   |lib/confparse.c
   682   208   |lib/innconf.c
   204   135   |include/inn/innconf.h
    96    38   |frontends/innconfval.c
----------------
  2145   810    total lines/statements

   573  lines had comments        26.7 %
   139  comments are inline       -6.5 %
   232  lines were blank          10.8 %
    36  lines for preprocessor     1.7 %
  1443  lines containing code     67.3 %
  2145  total lines              100.0 %

 18288  comment-chars             24.7 %
  2088  nontext-comment-chars      2.8 %
 21344  whitespace-chars          28.8 %
   954  preprocessor-chars         1.3 %
 31312  statement-chars           42.3 %
 73986  total characters         100.0 %

  4047  tokens, average length 5.99

  0.57  ratio of comment:code

    92  top-level blocks/statements
     5  maximum blocklevel
  2.45  ratio of blocklevel:code

Comment ratio went up considerably, preprocessor code went down, and block
level and maximum nesting both went down, so I consider that a very good
thing.  :)  Plus, much of the code in the new parser is generic, so we'll
start really seeing the gains when we start replacing things like the
2,244 lines of nnrpd/perm.c with something based on the new parser.

(To be fair, the old parser was very simple-minded and didn't need much in
the way of comments, whereas the generic code in the new parser is rather
more complex.)

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