[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Propagation of prefix change in "yylval" name

From: François PELLEGRINI
Subject: Propagation of prefix change in "yylval" name
Date: Wed, 28 Apr 2010 18:20:51 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100422 Mandriva/3.0.4-0.4mdv2009.1 (2009.1) Thunderbird/3.0.4

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,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]