hmurray at megapathdsl.net
Fri Jun 22 19:30:06 UTC 2018
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
> 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.
More information about the devel