[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Code that disapears
From: |
Akim Demaille |
Subject: |
Re: Code that disapears |
Date: |
Sat, 01 Mar 2003 14:26:27 +0100 |
User-agent: |
Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 |
>> @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.
- Re: Code that disapears,
Akim Demaille <=