Propagation of prefix change in "yylval" name

[François PELLEGRINI]

Hello all,

[Message also posted to the flex Sourceforge
bug tracker]

I have just a small request regarding the
interaction of Flex and Bison when using
prefix strings.

The tool versions I use are :
$ flex --version
flex 2.5.35
$ bison --version
bison (GNU Bison) 2.4.1

In order to protect the parser I generate
from collisions with third-party parsers,
I use the "-p" and "-P" options, respectively :

$ bison -pscotchyy -d -v parser_yy.y
$ flex -Pscotchyy parser_ll.l

However, as far as I have seen, I have to
hard-code the changes in the parser code
itself, which in my opinion should not be
the case. Indeed, when doing :

$ bison -pscotchyy -d -v parser_yy.y

in file "parser_yy.tab.c" I get :

#define yylval          scotchyylval

However, in file "parser_ll.l", where
I wrote things such as :

<lstrat>[0-9A-Za-z]         {
                              strncpy (yylval.STRING, yytext, PARSERSTRINGLEN);
                              yylval.STRING[PARSERSTRINGLEN - 1] = '\0';
                              return (METHODNAME);
                            }

I have no way to know that "yylval" is
no longer "yylval" but "scotchyylval" too.

Is there a clean way to use the contents
of the prefix variable set by the "-P" option
of flex in the code processed by flex (such
as a replication of the "#define" produced by
bison), rather than resorting to dirty "##"
agglutinations through an external macro
definition at parser-generated C code compile
time ?

Or is it up to Bison to add a copy of the #define
in its "parser_yy.tab.h" file ?

Thanks for all the great job,

A+,


                                f.p.