[Top][All Lists]

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

Re: YYEOF shouldn't be defined with bison -y

From: Dimitrios Apostolou
Subject: Re: YYEOF shouldn't be defined with bison -y
Date: Tue, 05 Dec 2017 02:32:09 +0100
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/25.3 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO)

On Mon, 04 Dec 2017 21:24:40 +0100,
Kaz Kylheku wrote:
> On 03.12.2017 18:34, Dimitrios Apostolou wrote:
> > Hello list,
> > 
> > I am configuring the build using AC_PROG_YACC, which invokes bison with "-y"
> > option.  But bison-generated parser compiled successfully, and YYEOF
> > extension
> > in the parser remained undetected.
> > 
> > Generating the parser with "byacc" on the other hand creates a file that
> > does
> > not compile because of undefined symbol YYEOF.
> What is your error report?
> Are you saying that you cannot boostrap a build of Bison using Byacc?

My error report has nothing to do with bootstrapping Bison, sorry for not
being clear.

I am generating a parser as part of a different project, and that project is
configured with AC_PROG_YACC. As such, it invokes Bison with "-y" option, and
I would expect that Bison tries hard to fail when the parser uses non-portable
features, such as YYEOF.

This is not the case however, and the project was released, and this was
discovered after longtime that somebody built it with byacc instead of
Bison. With that version of byacc, the generated parser C code failed to build
with "undefined symbol YYEOF".

I would expect that "bison -y" undefines YYEOF, so that the software that uses
YYEOF fails to build.

> The Bison source tree contains the generated parse-gram.c file, so I would
> expect that you don't need an installation of any kind of Yacc to be
> able to build it. (So if it is intended to work with Byacc but doesn't,
> it's a problem, but shouldn't be a blocker.)
> It is not wrong for Yacc implementations to introduce additional YY*
> identifiers; they are in the "Yacc namespace"; sort of like POSIX (or anyone
> else) can introduce errno macros beginning with E in the <errno.h> header.

Alright, so maybe it's not a bug. But if that's the case, what's the
recommended way to ensure that the parser is portable to most yacc flavours?


reply via email to

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