Re: Bison/flex compatibility revisited

[Paul Eggert]

Bruce Lilly <address@hidden> writes:

>    there is the possibility that a Bison YY or yy name might cause
>    strange things to happen with the included flex header (the
>    obvious example would be if Bison were to define
>    YY_HEADER_NO_UNDEFS as a macro taking one or more arguments).

Yes; that is the sort of possibility that I'm worried about.

In retrospect it would have been better if flex had used just some
subspace of the yy/YY namespace for private names (e.g.,
yyl/yyL/YYl/yyL), and if Bison had used some other subspace (e.g.,
yyy/yyY/YYy/YYY).  Then there would be no collision for private names.
On the Bison side, we can convert the names that are truly intended to
be private to use a yyy/yyY/YYy/YYY prefix.  Presumably the Flex side
can do the same, whenever it's convenient.

But this leaves us with the problem of the public names, i.e., the
names exported from flex or bison to user code, or to each other.  The
existing names can't be changed easily, for backward-compatibility
reasons.  Also, it'd be a bit confusing if all new Bison-generated
public names started with (say) yyy, as there are already too many
prefixes.  I don't see a simple solution here; the best I can see is
to try not to stumble into the other side's public names, and also to
try not to have too many public names of one's own.

> it would be nice to have some degree of control over what is exposed
> by the flex-generated header

I agree. I'm no expert here, but there do seem to be too many public
names by default with flex right now.  Surely they're not all intended
to be used by the user, or by Bison-generated code.


> 1. Flex header not generated or not included by parser
> 
>    Compiling the parser yields warnings such as
> 
>      y.tab.c: In function `yyparse':
>      y.tab.c:4321: warning: implicit declaration of function `yylex'

Just as a point of information: in C99 this is an error, since C99
requires that you must declare yylex before using it.  Similarly for
yyerror.  Bison does not generate prototypes for these functions; that
is the user's responsibility.  The user can satisfy this
responsibility by including a file generated by 'flex', or by doing it
by hand (e.g., by defining a macro for yyerror).