[Top][All Lists]

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

Re: Bison/flex compatibility revisited

From: Bruce Lilly
Subject: Re: Bison/flex compatibility revisited
Date: Wed, 26 Feb 2003 20:53:07 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

John wrote:
So if I either move code from an action to a separate module or
switch from a static to reentrant (or vice versa) lexical analyzer,
there's a great deal of rewriting to be done unless everything in
the header is exposed.

No. If you use the accessor methods everywhere, there is no problem
and you code works in actions as well as externally.

OK, though of course that won't work if the .l file is
used with lex or pclex, etc., but that's another story.
Has anybody profiled a static lexical analyzer to see
how much overhead the yyget_out etc. function calls
add to run time?

And there's still the issue of the macro renaming yyget_out to
fooget_out, which isn't available unless everything in the header
is exposed.

That's the point of the prefix! If you choose the prefix "foo", you
can not expect to call any "yy*" functions. They have all been renamed
to "foo*".

Bison and yacc invariably use yylex and yyerror.  I can use
the yy names in pattern actions, and if I decide to change
the prefixm the *only* thing I have to change is the flex option
(%option line or command line option).  Note that I can't even

#define yylex foolex
#include "flex-header.h"
int bar(void) { return yylex(); }

in my .y file or in any separate C file, because the undef
inside the flex-generated header clobbers my macro (yes, I
could put the macro after the flex header inclusion). Right
now I can include the flex-generated header and expose the
macros via #define YY_HEADER_NO_UNDEFS. If my makefile correctly
shows a dependency for y.tab.o on that header file, I can change
*only* the prefix option (line or command option) to flex and
everything works, w/o having to re-run bison on the .y file.
It would be great if I could do that w/o having to expose
everything or edit multiple files and rerun bison, and I cannot
imagine a scenario where I specify a prefix foo and *don't* want
the equivalent of #define yylex foolex, etc.  Can you?

reply via email to

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