Future/bison
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/bison.git synced 2026-03-19 17:23:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

(How Can I Reset @code{yyparse}): Reword the

Browse Source 
English a bit.  Fix fclose typo.  Change "const char" to "char
const", and use ANSI C rather than K&R for "main".  Suggest
YY_FLUSH_BUFFER over yyrestart (as that is what Flex recommends)
and suggest yy_switch_to_buffer.
This commit is contained in:
Paul Eggert
2003-05-12 19:34:21 +00:00
parent 163ab32161
commit 0e14ad772f
1 changed files with 19 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
doc/bison.texinfo
View File

@@ -6376,26 +6376,26 @@ This question is already addressed elsewhere, @xref{Recursion,
@node How Can I Reset @code{yyparse} @node How Can I Reset @code{yyparse}
@section How Can I Reset @code{yyparse} @section How Can I Reset @code{yyparse}
The following phenomenon gives raise to several incarnations, The following phenomenon has several symptoms, resulting in the
resulting in the following typical questions: following typical questions:
@display @display
I invoke @code{yyparse} several times, and on correct input it works I invoke @code{yyparse} several times, and on correct input it works
properly; but when a parse error is found, all the other calls fail properly; but when a parse error is found, all the other calls fail
too. How can I reset @code{yyparse}'s error flag? too. How can I reset the error flag of @code{yyparse}?
@end display @end display
@noindent @noindent
or or
@display @display
My parser includes support for a @samp{#include} like feature, in My parser includes support for an @samp{#include}-like feature, in
which case I run @code{yyparse} from @code{yyparse}. This fails which case I run @code{yyparse} from @code{yyparse}. This fails
although I did specify I needed a @code{%pure-parser}. although I did specify I needed a @code{%pure-parser}.
@end display @end display
These problems are not related to Bison itself, but with the Lex These problems typically come not from Bison itself, but from
generated scanners. Because these scanners use large buffers for Lex-generated scanners. Because these scanners use large buffers for
speed, they might not notice a change of input file. As a speed, they might not notice a change of input file. As a
demonstration, consider the following source file, demonstration, consider the following source file,
@file{first-line.l}: @file{first-line.l}:
@@ -6409,20 +6409,20 @@ demonstration, consider the following source file,
.*\n ECHO; return 1; .*\n ECHO; return 1;
%% %%
int int
yyparse (const char *file) yyparse (char const *file)
{ {
yyin = fopen (file, "r"); yyin = fopen (file, "r");
if (!yyin) if (!yyin)
exit (2); exit (2);
/* One token only. */ /* One token only. */
yylex (); yylex ();
if (!fclose (yyin)) if (fclose (yyin) != 0)
exit (3); exit (3);
return 0; return 0;
} }
int int
main () main (void)
{ {
yyparse ("input"); yyparse ("input");
yyparse ("input"); yyparse ("input");
@@ -6439,7 +6439,7 @@ input:2: World!
@end verbatim @end verbatim
@noindent @noindent
then instead of getting twice the first line, you get: then instead of getting the first line twice, you get:
@example @example
$ @kbd{flex -ofirst-line.c first-line.l} $ @kbd{flex -ofirst-line.c first-line.l}
@@ -6449,12 +6449,15 @@ input:1: Hello,
input:2: World! input:2: World!
@end example @end example
Therefore, whenever you change @code{yyin}, you must tell the Lex Therefore, whenever you change @code{yyin}, you must tell the
generated scanner to discard its current buffer, and to switch to the Lex-generated scanner to discard its current buffer and switch to the
new one. This depends upon your implementation of Lex, see its new one. This depends upon your implementation of Lex; see its
documentation for more. For instance, in the case of Flex, a simple documentation for more. For Flex, it suffices to call
call @samp{yyrestart (yyin)} suffices after each change to @samp{YY_FLUSH_BUFFER} after each change to @code{yyin}. If your
@code{yyin}. Flex-generated scanner needs to read from several input streams to
handle features like include files, you might consider using Flex
functions like @samp{yy_switch_to_buffer} that manipulate multiple
input buffers.
@node Strings are Destroyed @node Strings are Destroyed
@section Strings are Destroyed @section Strings are Destroyed