Re: Code that disapears

[Akim Demaille]

 >> @output_file_name@ and so forth should be replaced by a definition
 >> of output_file_escaped, and restore the role played by M4 in the
 >> output.

 Paul> I can't see any way to do that with arbitrary file names and
 Paul> GNU m4 1.4.  File names can contain characters like ",", "(",
 Paul> "@", and "[", and these are all problematic in M4, the way
 Paul> we're using M4.

Paul, I don't care about this problem until it happens.  I don't care
about user putting */ in the file name, I don't care about people
putting ( or \ in file names.  But I care about the features that used
to work for 99% of cases, but are turned off because of 1% of dark
corners.

I know I will spend some time in the future on M4 and have more means
to reach the 100%.  In the meanwhile pedantic accuracy is a burden.


 >> (BTW, I don't understand why the guard has disappeared here).

 Paul> Unless I'm misunderstanding your point, the header guard hasn't
 Paul> disappeared.  It's been replaced by this:

 Paul> /* FIXME: This is wrong, we want computed header guards.
 Paul> I don't know why the macros are missing now. :( */
 Paul> #ifndef PARSER_HEADER_H
 Paul> # define PARSER_HEADER_H

 Paul> Perhaps you're referring to the old b4_header_guard macro?
 Paul> That was removed because it didn't work in the presence of
 Paul> arbitrary file names.

That was extreme.

 Paul> We need a better solution, one that works on arbitrary file
 Paul> names.  The current solution is merely a stopgap (but at least
 Paul> it does not dump core....).

... when somebody writes code aiming at having it fail.

 Paul> I don't fully understand the comment that "#ifndef
 Paul> PARSER_HEADER_H" is "wrong".  Is this because it is intended
 Paul> for C++ programs to include multiple, independent
 Paul> Bison-generated parser headers, and each header should have a
 Paul> different PARSER_HEADER_H macro?  

Correct.

 Paul> That is a laudable goal, but if so, then other code in the
 Paul> parser headers is also "wrong", since it also isn't reliable in
 Paul> the presence of multiple parser headers.  Examples include the
 Paul> definitions of YYLSP_NEEDED and of YYERROR_VERBOSE.  Whatever
 Paul> method is used to fix this other code can also be used to fix
 Paul> the PARSER_HEADER_H problem.

Indeed, that's well spotted.

 Paul> While we're on the subject, there is another minor problem with
 Paul> the PARSER_HEADER_H stopgap: it infringes on the user name
 Paul> space.  That macro name should start with YY.

I don't care.  Again, that's useless pedantism.  I'm tired of spending
time fixing these bits: there are usable features that are now
deactivated in Bison.  That's wrong.