help-bison
[Top][All Lists]
Advanced

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

Re: set flex start conditions from bison?


From: Rui Maciel
Subject: Re: set flex start conditions from bison?
Date: Thu, 27 Aug 2009 19:52:27 +0100
User-agent: KNode/4.3.0

Akim Demaille wrote:

> Please, keep everything public, send them here too.

To be fair, I've also sent it to this mailing list. It appears that a message 
posted to this mailing list 
through gmane's newsgroup arrives faster than one sent through email.


> I don't know what Flex you use, but using 2.5.35 it does not compile:
> you're using push_state, which is static in the scanner.c file, from
> the parser.c file.

Yes, that's the most recent SNAFU I stumbled on. Yet, it only goes that far if 
I add to the flex source 
file the undocumented, unexplained #define YY_HEADER_EXPORT_START_CONDITIONS, 
which seems like a bit of a 
hack and not a good way to go around things.


> Reading the Flex header file, I was most amused to read the following:
> 
> #define YY_FLEX_MAJOR_VERSION 2
> #define YY_FLEX_MINOR_VERSION 5
> #define YY_FLEX_SUBMINOR_VERSION 35
> #if YY_FLEX_SUBMINOR_VERSION > 0
> #define FLEX_BETA
> #endif
> 
> Given their definitions of FLEX_BETA, I wonder if there ever existed a
> true release of Flex :)

Good point :D


> Back to the point.  I do not have the problem you have: s_element is
> correctly replaced as expected.
> 
> address@hidden /tmp/foo $ grep '%[sx]' msh.l
> %x s_element
> address@hidden /tmp/foo $ grep s_element msh.y
> { yy_push_state(s_element); }
> address@hidden /tmp/foo $ cc -E msh.tab.c | grep yy_push_state
> { yy_push_state(1); }
> 
> 
> It seems bizarre to me to play with start conditions and yy_push_state
> from the parser.  I would rather write some wrapper function in the
> scanner.l file, say scan_enter_element_mode(), and use that function
> from my parser.

Why is that a better alternative to simply calling yy_push_state() and co from 
within the bison code? 
Handling yy_push_state() directly from bison appears to be a cleaner way of 
doing things.


> I agree it also seems bizarre that start conditions are defined in the
> header file, but that yy_push_state is static.

Is it possible that this is a flex bug?


Rui Maciel





reply via email to

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