Re: Bison/flex compatibility revisited

[John]

> > We can't guarantee that we will use those macros in the future in
> > order to create the prefix namespace. There is a better way to
> > solve this without macros at all.
> >
> > Future revisions of flex may generate the mangled symbols
> > directly, instead of passing the buck to the C preprocessor as it
> > does now.
>
> That should work OK w/ bison *if* the bison-generated macros are not
> #undef'ed (as is currently the case when the flex- generated header
> file that declares the function is included w/o
> YY_HEADER_NO_UNDEFS).  However, that won't help use of flex w/ yacc,
> byacc, etc. -- there's some dicussion of the issues in the O'Reilly
> yacc & lex book.

Can you elaborate? The current plan is to go ahead and generate
the prefixed linkable symbols directly, eliminating many of the flex
macros. Do you see a reason why bison macros will interfere with this
scheme? Just to be clear, the generated code will look like this:

        int xyzlex(void) {
                ...
        }

instead of junk like this:

        #define yylex xyzlex
        #ifdef YY_REENTRANT
        #define YYLEX_ARGS void * scanner
        #else
        #define YYLEX_ARGS void
        #endif
        #define YY_DECL int yylex YY_PROTO((YYLEX_ARGS))
        YY_DECL {
            ...
        }