[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:1.9.1.9) 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,
A+,
f.p.
- Propagation of prefix change in "yylval" name,
François PELLEGRINI <=