bug-bison
[Top][All Lists]
Advanced

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

Bison/flex interface (Was Re: [GNU bison 1.75b] testsuite.log: 14 failur


From: Bruce Lilly
Subject: Bison/flex interface (Was Re: [GNU bison 1.75b] testsuite.log: 14 failures)
Date: Mon, 06 Jan 2003 08:31:34 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

Akim Demaille wrote:
| Akim Demaille wrote:
| >  Bruce> Finally, there are some bad interactions between bison 1.75b
| >  Bruce> and flex 2.5.23: bison unconditionally #defines YYLTYPE, which
| >  Bruce> causes grief when location tracking is undesired,
| > Why  exactly did this cause a problem?
| | Flex 2.5.2[345] %option header generates a header file that contains
| #ifdef YYLTYPE
| and that causes inappropriate declataions for yylex, etc. when the
| flex-generated header is included in the bison-generated parser.

YYLTYPE was a name invented in the Bison world: how can they use it
without asking us?  It seems to me that Flex cannot know what the
signature of yylex will be, it also depends whether the parser is pure
or not.  Unless explicitly told by the user, I fail to see how flex
could decide what the prototype of yylex will be.

I believe flex uses it to determine whether or not bison is expecting
the lexical analyzer to do provide a sort of location tracking (but
that fails as YYLTYPE was *unconditionally* defined).  Flex does have
options that indicate bison pure-parser etc.  The YYLTYPE issue was
also reported on the help-flex list ca. 2002-11-26,

As flex is providing the yylex function, it obviously *needs* to be
able to determine its "signature".  I believe that the flex maintainers
are making a good-faith effort to have flex work smoothly with bison --
but there needs to be better coordination between the two groups.

Here's the situation in which the issues mentioned arise:
Bison pure parser, no location tracking
Bison generates y.tab.h
Flex reentrant lexical analyzer, w/ bison interface for pure parser,
   many start conditions
Flex builds lexical analyzer and generates a header which includes
   start condition definitions, yylex declaration, etc. (via flex
   %option header)
y.tab.c #includes flex-generated header (for start conditions,
   yylex declaration, etc. via %{ %} in 1st section of .y file)
YY_HEADER_NO_UNDEFS is also defined prior to #including the flex-
   generated header (necessary so that start condition definitions
   are visible in the parser action code)

For the most part, bison and flex work well together, even in this
relatively complex scenario, but the interface needs a little fine
tuning.  I can work around the issues in the beta versions, but it
would be nice if the interface would work a bit more smoothly by the
time flex 2.6 and bison 2 are released.





reply via email to

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