Re: Bison/flex compatibility revisited

[John]

>      y.tab.c: In function `yyparse':
>      y.tab.c:4321: warning: implicit declaration of function `yylex'

The solution to the above error is the same as it has always been for
bison code.  You must predeclare yylex. The following line of code in
your bison input will suffice:

    extern int yylex(void);



> 2. Flex header generated and included by parser, but w/o the
>    magic #define YY_HEADER_NO_UNDEFS (or equivalent) before the
>    inclusion.
>
>    Same compilation warnings as above, same consequences.  However,
>    there is the potential for *some* name-space clashes, as *some*
>    of the flex-defined names are visible (e.g. YY_FLEX_SUBMINOR_VERSION,
>    which is a recent addition that probably was overlooked; there
>    are others).

By defining YY_HEADER_NO_UNDEFS, you are explicitly asking flex not to
clean up the YY namespace. I don't see how this is a bug if you ask
for flex to leave all the YY_* garbage in your namespace.

> The only way (currently) to make the yylex declaration that is in
> the flex-generated header visible (and the macro renaming it if
> flex's prefix option is used) is to define YY_HEADER_NO_UNDEFS prior
> to the inclusion, and that's the next scenario

This is entirely incorrect. The declaration of yylex is visible
without having to do any macro tricks.


> 4. For whatever reason, the programmer doesn't care about the
>     yylex macro or prototype, but needs start condition definitions

There is a macro YY_HEADER_EXPORT_START_CONDITIONS for this explicit
purpose.


> Aside from that, from my perspective it would be nice to
> have some degree of control over what is exposed by the
> flex-generated header, rather than the current basically
> all-or-nothing choice.

You currently have these options:
  1. Expose only the documented flex API function -- NO MACROS.
  2. Expose ALL macros -- why anyone wants this I have no idea.
  3. Expose the start conditions.

What more control do you want? Anything else is an internal flex macro
and is not exposed -- nor should it be.