Manual

112 Bison 2.3
{
}
yyparse ("input");
yyparse ("input");
return 0;
If the file ‘input’ contains
input:1: Hello,
input:2: World!
then instead of getting the first line twice, you get:
$ flex -ofirst-line.c first-line.l
$ gcc -ofirst-line first-line.c -ll
$ ./first-line
input:1: Hello,
input:2: World!
Therefore, whenever you change yyin, you must tell the Lex-generated scanner to discard
its current buffer and switch to the new one. This depends upon your implementation of
Lex; see its documentation for more. For Flex, it suffices to call ‘YY_FLUSH_BUFFER’ after
each change to yyin. If your Flex-generated scanner needs to read from several input
streams to handle features like include files, you might consider using Flex functions like
‘yy_switch_to_buffer’ that manipulate multiple input buffers.
If your Flex-generated scanner uses start conditions (see section “Start conditions” in
The Flex Manual), you might also want to reset the scanner’s state, i.e., go back to the
initial start condition, through a call to ‘BEGIN (0)’.
11.3 Strings are Destroyed
My parser seems to destroy old strings, or maybe it loses track of
them. Instead of reporting ‘"foo", "bar"’, it reports
‘"bar", "bar"’, or even ‘"foo\nbar", "bar"’.
This error is probably the single most frequent “bug report” sent to Bison lists, but is
only concerned with a misunderstanding of the role of the scanner. Consider the following
Lex code:
%{
#include
char *yylval = NULL;
%}
%%
.* yylval = yytext; return 1;
\n /* IGNORE */
%%
int
main ()
{
/* Similar to using $1, $2 in a Bison action. */
char *fst = (yylex (), yylval);