Dump bison

[Hal Murray]

esr at thyrsus.com said:
> My goal was a visualization of the control structures the rest of the daemon
> sees - so, as far inside and as digested as possible (this is what the code I
> deleted was aiming at, I think). 

The old code printed stuff out to recreate the input config file.  For things 
like server and restrict that scanned the internal lists of structs.  Lots of 
other stuff just sets global variables - no structure involved.

A list of structs isn't very complicated so that isn't testing much more than 
intercepting the callouts.  Your approach would make more sense if our parse 
tree had a more complicated structure.

Some of the internal data structures have a hash table in addition to the 
list.  It would be nice to exercise that code.  That requires something like 
the current test routines, but they need a way to load the data they want to 
play with.

> It...never actually occurred to me that we might be worried about the parsing
> *itself.*  Duh.  Blind spot on my part, I guess I'm just too used to Yacc/Lex
> parsers Just Working. 

I'm not a yacc wizard.  I think it would be nice if we had something that 
exercised all the options the parser was expected to handle.  Partly, it would 
be another chunk of documentation.


I agree that this isn't high priority now, mostly because the parser isn't 
changing.  If we figure out a good architecture, it should work for 
authreadkeys too, and maybe the leap seconds code.

The other thing that would be good to check is the error cases.  I think that 
would work if the test structure had a dummy msyslog (or kludgy flag in the 
real one) to skip printing the time and process number.


It would be better if we had some setup that actually tested all the config 
options at run time.  I don't have any ideas on how to do that.


-- 
These are my opinions.  I hate spam.