Re: Bison/flex compatibility revisited

[Bruce Lilly]

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?