[Top][All Lists]
[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