Re: proposed patch for Bison core dumps when using lalr1.cc

[Tim Van Holder]

> > I disagree - there's something icky about a tool generating files
> > I didn't request - if I tell bison to make me a grammar in foo.cc
> > from foo.yy I do not expect to get 3 header files generated for me
> > as well - especially if that list of additional files is not stable
> > across bison versions (and I suspect that will be the case, 
> especially
> > for skeletons that evolve).
> 
> That *is* an interesting concept "files I didn't request".  
> By definition,
> the files created by the tool you used were _requested_.

I mean that if I tell a tool '.... -o <outputfile>', then I expect
outputfile to be created, and probably nothing else (in the case of
bison, the --defines option specifically requests a .h file as well).
Using a different skeleton should not really change this IMHO.  I would
expect bison's output to be a black box, with a single entry point
(or a single class, as the case may be) - whatever it uses to provide
its functionality is nobody's business but the parser - so no extra
files should be necessary.
The only exception to this would be a .h file - with two valid uses:
 1) provide a declaration for the parser interface class, so client code
    can actually use the parser,
 2) provide declarations needed for lexer/parser communication, i.e.
    declarations of tokens, and the types for yylval and yylloc (though
    even that would not be necessary if the parser class provides a
    set_location(file, line, col) type function - then whatever type the
    parser uses internally to hold locations becomes pretty much
    irrelevant).
One real exception would be skeletons for languages where having a
single
file to hold a complete parser is actually impossible (Java comes to
mind).

In the end, it's not really that important I guess; it mainly boils down
to style/design issues.

> I agree that newly created file can be a problem but the C++ parser is
> still not documented, so it has more freedom than the others. 
>  Actually,
> I'm surprised to learn tht you use it.  Could you provide 
> more feedback about it?

I wasn't really using it - I simply wanted to see what kind of output I
got, so I ran an existing grammar through bison, specifying the c++
skeleton, which exposed the bug in question.

> > At the very least bison should provide an option (--clean?) 
> that cleans
> > up after itself properly.
> 
> Why not, indeed.  That sounds good to me.