[Top][All Lists]

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

Re: Bison 1.30f

From: Paul Eggert
Subject: Re: Bison 1.30f
Date: Thu, 13 Dec 2001 18:09:11 -0800 (PST)

> From: Akim Demaille <address@hidden>
> Date: 13 Dec 2001 11:36:54 +0100
> bison is meant to produce compilation units, not headers.  So I fail
> to see why it is so important not to import the standard symbols.

I think it was one of RMS's original goals when writing Bison.  That
is why the manual says "Aside from the token type names and the
symbols in the actions you write, all variable and function names used
in the Bison parser file begin with `yy' or `YY'."

Also, strictly speaking it is required for POSIX conformance.
POSIX 1003.1-2001 says:

   Conforming applications shall not use names beginning in yy or YY
   since the yacc parser uses such names. Many of the names appear in the
   final output of yacc, and thus they should be chosen to conform with
   any additional rules created by the C compiler to be used. In
   particular they appear in #define statements.

Since the C standard says that a conforming application can use, say,
the identifier `offsetof' so long as it doesn't include any standard
headers that define `offsetof', this means the generated parser must
be able to have code that does weird things like that.

> I am talking about _real_ C++ output, i.e., a Parser class.  You are
> referring to making C parsers compile with strict C++ rules.

OK, I see.  As far as I know we've achieved the latter (more modest)
goal on GNU systems, and have come pretty close on non-GNU systems.
(But I am not a C++ expert.)

The former goal would be better, of course.

reply via email to

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