hmurray at megapathdsl.net
Tue Jun 19 06:27:47 UTC 2018
> The problem with the new-parser-generator theory is that as much fun as I'd
> have doing it, the net effect on stability and maintainability would probably
> be negative. There's that how-do-you-know-you-specced- the-same-grammar
> problem again.
Actually, I think the stability would improve. We would probably build a test
harness that the current setup lacks.
There used to be code to write out the parser results. It wrote out the
in-memory version, not from the parser callouts. But you could diff it with
the input if your input was in the correct order.
When we ripped that stuff out, why didn't we add something better? I'm
thinking of a simple module that passes in a file name and catches all the
callouts and stubs them with simple printfs - something off to the side rather
than cluttering up ntpd itself.
There are several ways we could fix the warnings.
One would be to patch the generated code. Run bison. Edit by hand until the
compiler is happy. Save those edits as a patch file. Add the patch file to
git as source code. Teach waf to apply the patch... As long as the patch is
something simple like dropping in an endcase, that's probably reasonable to
The simplest solution is probably John Bell's suggestion. Hack waf to filter
the flags used to compile the parser to not use the option that generates the
warnings.. - even if it would be used for the rest of the compiles.
> So, in sum, I think living with a warning or two is the least bad option. The
> second least bad is that I slightly customize the Bison parser skeleton to
> make the problem go away; of course then we'd have to maintain that through
> Bison upgrades.
I agree that living with a few warnings is probably the right approach. At
least for now. But I think it's good to discuss other options.
Maintaining a fixed version of Bison seems like a bad idea. For something
like this, I'd expect upstream would accept a patch. That fixes the warnings
when a new version of Bison is released and distros adopt it.
Currently, we require Bison in the build environment. We don't really need
that. We only need Bison to run on some system we have access to. Then we
could treat the output as source and put it in git. It adds a layer of
complexity that I'm happy we don't have, but it is a possibility.
The approach of saving the Bison output also applies to using a modern parser.
If it isn't widely available, we have the option of running it on one system
and capturing the output to use on other systems.
These are my opinions. I hate spam.
More information about the devel