Re: Bison/flex compatibility revisited

[John]

> No, there is *no* use of the flex API in the .y file.
> The *only* use of flex/lex API in y.tab.c is the
> bison/yacc-generated call to yylex().

Calling yylex() constitutes use of the flex API. If you change the
flex prefix, then the API changes, namely yylex() becomes foolex().
The compiled y.tab.o will not link and must be edited/rebuilt to
reflect the new flex API.


> You might try to actually *understand* the issues rather than being
> dismissive.

If I were being dismissive, I wouldn't answer your questions.  I
investigated, for several hours, your claims about the header files
the other day. I patched flex to omit the 16 accidental YY macros that
slipped in. I do understand the issues here. I'm trying to explain to
you the point of the prefix, which is to place flex code in a
different namespace -- not the "yy" namespace.

Imagine if flex generated foolex() directly, instead of by using
"#define yylex foolex".  There would be no yylex(). The symbol yylex()
for all intents and purposes should NOT exist if the prefix has been
changed. Someday, we might generate the code in this manner, since the
resulting scanner would be much easier to read without all the macros.