X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/b83f0407c634814049e58f5ab14cc14c1daaa39f..927c15577418c9c18feea508854a3f49bb03aa9f:/doc/bison.texinfo?ds=sidebyside

diff --git a/doc/bison.texinfo b/doc/bison.texinfo
index 7b665633..609f870b 100644
--- a/doc/bison.texinfo
+++ b/doc/bison.texinfo
@@ -693,7 +693,7 @@ arrange for it to call @code{yyparse} or the parser will never run.
 @xref{Interface, ,Parser C-Language Interface}.
 
 Aside from the token type names and the symbols in the actions you
-write, all variable and function names used in the Bison parser file
+write, all symbols defined in the Bison parser file itself
 begin with @samp{yy} or @samp{YY}.  This includes interface functions
 such as the lexical analyzer function @code{yylex}, the error reporting
 function @code{yyerror} and the parser function @code{yyparse} itself.
@@ -702,6 +702,15 @@ Therefore, you should avoid using C identifiers starting with @samp{yy}
 or @samp{YY} in the Bison grammar file except for the ones defined in
 this manual.
 
+In some cases the Bison parser file includes system headers, and in
+those cases your code should respect the identifiers reserved by those
+headers.  On some non-@sc{gnu} hosts, @code{<alloca.h>},
+@code{<stddef.h>}, and @code{<stdlib.h>} are included as needed to
+declare memory allocators and related types.  In the same situation,
+C++ parsers may include @code{<cstddef>} and @code{<cstdlib>} instead.
+Other system headers may be included if you define @code{YYDEBUG}
+(@pxref{Debugging, ,Debugging Your Parser}).
+
 @node Stages
 @section Stages in Using Bison
 @cindex stages in using Bison
@@ -4507,9 +4516,8 @@ produce parsers that are very large.  In practice, Bison is more useful
 as it is now.
 
 When the problem arises, you can often fix it by identifying the two
-parser states that are being confused (using @samp{-v}
-(@pxref{Invocation, ,Invoking Bison}) can help), and adding something to
-make them look distinct.  In the above example, adding one rule to
+parser states that are being confused, and adding something to make them
+look distinct.  In the above example, adding one rule to
 @code{return_spec} as follows makes the problem go away:
 
 @example
@@ -4923,8 +4931,14 @@ of the grammar file (@pxref{Prologue, , The Prologue}). Alternatively, use the
 @samp{-t} option when you run Bison (@pxref{Invocation, ,Invoking Bison}).
 We always define @code{YYDEBUG} so that debugging is always possible.
 
-The trace facility uses @code{stderr}, so you must add
-@w{@code{#include <stdio.h>}} to the prologue unless it is already there.
+The trace facility outputs messages with macro calls of the form
+@code{YYFPRINTF (YYSTDERR, @var{format}, @var{args})} where
+@var{format} and @var{args} are the usual @code{printf} format and
+arguments.  If you define @code{YYDEBUG} but do not define
+@code{YYFPRINTF}, @code{<stdio.h>} is automatically included and the
+macros are defined to @code{fprintf} and @code{stderr}.  In the same
+situation, C++ parsers include @code{<cstdio.h>} instead, and use
+@code{std::fprintf} and @code{std::stderr}.
 
 Once you have compiled the program with trace facilities, the way to
 request a trace is to store a nonzero value in the variable @code{yydebug}.
@@ -5003,7 +5017,7 @@ Here @var{infile} is the grammar file name, which usually ends in
 @samp{.y}.  The parser file's name is made by replacing the @samp{.y}
 with @samp{.tab.c}.  Thus, the @samp{bison foo.y} filename yields
 @file{foo.tab.c}, and the @samp{bison hack/foo.y} filename yields
-@file{hack/foo.tab.c}. It's is also possible, in case you are writting
+@file{hack/foo.tab.c}. It's is also possible, in case you are writing
 C++ code instead of C in your grammar file, to name it @file{foo.ypp}
 or @file{foo.y++}. Then, the output files will take an extention like
 the given one as input (repectively @file{foo.tab.cpp} and @file{foo.tab.c++}).