Re: Bison 1.30f

[Paul Eggert]

> Date: Wed, 19 Dec 2001 12:10:36 +0100
> From: Hans Aberg <address@hidden>
> 
> The Yacc compatible program must be able to produce such names in some
> mode, but not always in any mode.

Yes, and the only modes that are required are the ones prescribed by
the standard.  However, it makes sense (all other things being equal)
to use the same solution for both standard modes and for extensions.


> The question is whether POSIX requires the names to be visible to the
> preprocessor. Do you have a quote that says that the names must be visible
> to the preprocessor?

POSIX says that yacc must output "C source code, conforming to the ISO
C standard".  Almost all names in C source code are visible to the
preprocessor.  There are a few exceptions (comments, strings, and a
few positions in "#" lines) but they do not apply here.  I assume C++
is similar.


> >> to me, it says that other programs
> >> should not use them as the Yacc program may use them.
> >
> >That's another way of saying the same thing.
> 
> Nope. If one is sure to not use them, then one is sure to be able to
> combine that with a Yacc generated parser, as it can be set to only produce
> such names.

Sorry, I can't parse your statement.  But perhaps the following may
help clarify things.  This is not merely a matter of linking y.tab.o
with other .o files.  This is a matter of compiling a single y.tab.c
correctly.  y.tab.c contains some code written by the user, and other
code written by Bison.  The names in those two pieces of code must not
clash.  This includes preprocessor names, which can clash with
non-preprocessor names.


> Besides, I think that POSIX is outdated relative Bison, as one always can
> use a favorite prefix: Choose yy if one likes to, and that suffices.

No, because the -p option affects only external names produced by
yacc.  That is, -p principally is a tool to affect the .o files.  The
standard says that names beginning with yy and YY are reserved
regardless of whether you use -p.  That is why yacc can safely
generate symbols starting with yy and YY.


> In addition, I have several times used more than one parse in the same
> program, and POSIX does not says how to handle such a situation.

Yes it does: you can use -p.  This prevents the parsers' external
symbols from colliding.


> >> Also, C++ isn't (I take it) part of POSIX, so whatever POSIX says
> >> about macros under C, it is not valid under C++.
> >
> >True, but C++ is similar to C, and has similar problems with
> >preprocessor names.  All other things being equal, it's simpler for
> >both users and maintainers if we treat the languages similarly.
> 
> Nope: one of the main development goals of C++ is to replace uses that in C
> are handled by macros (and thus are not part of the C language itself) with
> C++ language constructs. This makes it easier for compilers to handle it
> efficiently.

That may be a goal, but it hasn't been achieved.  Until the
preprocessor language is removed from all active C++ compilers, Bison
will need to assume that C++ programmers will (ab)use the preprocessor.
It's not Bison's job to enforce programming style rules.