bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code that disapears


From: Paul Eggert
Subject: Re: Code that disapears
Date: Tue, 4 Feb 2003 00:03:58 -0800 (PST)

> From: Akim Demaille <address@hidden>
> Date: Sun, 02 Feb 2003 12:15:58 +0100
> 
> I often put in some code that is not yet used, but plans to be used.
> I'd like it to stay there.

In this particular case, the code was used, but its use was removed.
It's not always obvious what the right thing to do is in this case.
Sorry if I made the wrong decision.

> @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.

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

We need to support arbitrary Unix file names.  Bison should not go
haywire simply because a user decides to put a quote character or an
escape character in a file name.

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

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

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

Perhaps you're referring to the old b4_header_guard macro?  That was
removed because it didn't work in the presence of arbitrary file
names.  We need a better solution, one that works on arbitrary file
names.  The current solution is merely a stopgap (but at least it does
not dump core....).

I don't fully understand the comment that "#ifndef PARSER_HEADER_H" is
"wrong".  Is this because it is intended for C++ programs to include
multiple, independent Bison-generated parser headers, and each header
should have a different PARSER_HEADER_H macro?  That is a laudable
goal, but if so, then other code in the parser headers is also
"wrong", since it also isn't reliable in the presence of multiple
parser headers.  Examples include the definitions of YYLSP_NEEDED and
of YYERROR_VERBOSE.  Whatever method is used to fix this other code
can also be used to fix the PARSER_HEADER_H problem.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]