Re: Segmentation fault using lalr1.cc

[Akim Demaille]

 Paul> Tim Van Holder <address@hidden> writes:
 >> This is because lalr1.cc also has '#include @output_header_name@'.
 >> With that wrapped in an m4_if as well, bison no longer crashes.

 Paul> Thanks; I'll send a proposed patch to bison-patches and will cc: to you.

 >> I don't see why bison couldn't/shouldn't warn "Skeleton uses
 >> @output_header_name@ which is only available if the -d option is
 >> given" (or something similar).

 Paul> Good suggestion.

Actually, in the case of lalr1.cc, the header is not optional.  I did
not have the time to finish everything there :(  There is a lot of
these things that should move back into m4 world.  I do hope 1.5 will
be out some day.

 >> BTW, 'bison -S lalr1.cc foo.y' still produces a .c file; this seems a
 >> bit odd.

 Paul> Yes, it seems odd to me too.  But I don't use C++ so I am not
 Paul> well-qualified to judge about Bison's handling (or mishandling) of
 Paul> C++.

The user is still the chief here.  If she says .y, she gets .c.  If
she says .yy, she gets the .cc, but if she turns out to be of the .cpp
kind, she can use .ypp.