Akim Demaille 2f7097d1b1 yacc.c, glr.c: fix crash when reporting errors in consistent states
The current code for yysyntax_error for %define parse.error verbose is
fishy (given that YYEMPTY is -2, invalid argument for yytname[]):

    static int
    yysyntax_error ([...])
    {
      YYPTRDIFF_T yysize0 = yytnamerr (YY_NULLPTR, yytname[yytoken]);
    [...]
      if (yytoken != YYEMPTY)

A nearby comment reports

    The only way there can be no lookahead present (in yychar) is if
    this state is a consistent state with a default action.  Thus,
    detecting the absence of a lookahead is sufficient to determine
    that there is no unexpected or expected token to report.  In that
    case, just report a simple "syntax error".

So it _is_ possible to call yysyntax_error with yytoken == YYEMPTY,
albeit quite difficult when meaning to, so virtually impossible by
accident (after all, there was never a bug report about this).

I failed to produce a test case, but Joel E. Denny provided me with
one (added to the test suite below).  The yacc.c skeleton fails on
this, and once fixed dies on a second problem.  The glr.c skeleton was
also dying, but immediately of this second problem.

Indeed we were not allocating space for the error message's final \0.
This was hidden by the fact that we only had error messages with at
least an unexpected token displayed, so with at least one "%s" in the
format string, whose size (2) was included (incorrectly) in the final
size of the message (where the %s have been replaced by the actual
content).

* data/skeletons/glr.c, data/skeletons/yacc.c (yysyntax_error):
Do not invoke yytnamerr on YYEMPTY.
Clarify the computation of the length of the _final_ error message,
with the NUL terminator but without the '%s's.
* tests/conflicts.at (Syntax error in consistent error state):
New, contributed by Joel E. Denny.
2019-11-29 18:21:43 +01:00
2019-11-11 15:59:53 +01:00
2019-11-18 09:15:35 +01:00
2019-01-05 14:58:05 +01:00
2019-11-19 21:15:00 +01:00
2019-09-22 07:48:10 +02:00
2019-11-11 15:41:29 +01:00
2019-11-11 15:41:29 +01:00
2019-04-23 19:28:08 +02:00
2019-11-20 07:10:27 +01:00
2019-10-17 11:51:20 -07:00
2019-09-22 07:48:10 +02:00
2006-01-22 07:59:51 +00:00
2006-01-22 07:59:51 +00:00
2019-01-05 14:58:05 +01:00
2019-10-17 11:51:20 -07:00
2019-11-11 15:59:53 +01:00
2019-11-20 07:10:27 +01:00
2019-11-11 15:59:53 +01:00
2007-08-15 20:21:33 +00:00
2019-11-20 07:49:44 +01:00
2019-01-05 14:58:05 +01:00
2019-11-22 09:02:06 +01:00
2019-01-05 14:58:05 +01:00
2019-10-21 08:53:06 +02:00

This package contains the GNU Bison parser generator.

Installation

Build from git

Here are basic installation instructions for a repository checkout:

$ git submodule update --init
$ ./bootstrap

then proceed with the usual configure && make steps.

The file README-hacking.md ss about building, modifying and checking Bison.

Build from tarball

See the file INSTALL for generic compilation and installation instructions.

Bison requires GNU m4 1.4.6 or later. See https://ftp.gnu.org/gnu/m4/m4-1.4.6.tar.gz.

Colored diagnostics

As an experimental feature, diagnostics are now colored, controlled by the --color and --style options.

To use them, install the libtextstyle library before configuring Bison. It is available from https://alpha.gnu.org/gnu/gettext/, for instance https://alpha.gnu.org/gnu/gettext/libtextstyle-0.8.tar.gz.

The option --color supports the following arguments:

  • always, yes: Enable colors.
  • never, no: Disable colors.
  • auto, tty (default): Enable colors if the output device is a tty.

To customize the styles, create a CSS file, say bison-bw.css, similar to

/* bison-bw.css */
.warning   { }
.error     { font-weight: 800; text-decoration: underline; }
.note      { }

then invoke bison with --style=bison-bw.css, or set the BISON_STYLE environment variable to bison-bw.css.

Relocatability

If you pass --enable-relocatable to configure, Bison is relocatable.

A relocatable program can be moved or copied to a different location on the file system. It can also be used through mount points for network sharing. It is possible to make symlinks to the installed and moved programs, and invoke them through the symlink.

See "Enabling Relocatability" in the documentation.

Internationalization

Bison supports two catalogs: one for Bison itself (i.e., for the maintainer-side parser generation), and one for the generated parsers (i.e., for the user-side parser execution). The requirements between both differ: bison needs ngettext, the generated parsers do not. To simplify the build system, neither are installed if ngettext is not supported, even if generated parsers could have been localized. See http://lists.gnu.org/archive/html/bug-bison/2009-08/msg00006.html for more details.

Questions

See the section FAQ in the documentation (doc/bison.info) for frequently asked questions. The documentation is also available in PDF and HTML, provided you have a recent version of Texinfo installed: run make pdf or make html.

If you have questions about using Bison and the documentation does not answer them, please send mail to help-bison@gnu.org.

Bug reports

Please send bug reports to bug-bison@gnu.org. Be sure to include the version number from bison --version, and a complete, self-contained test case in each bug report.

Copyright statements

For any copyright year range specified as YYYY-ZZZZ in this package, note that the range specifies every single year in that closed interval.

Description
No description provided
Readme 18 MiB
Languages
C 61%
M4 11.7%
C++ 11.3%
Shell 4.1%
XSLT 3.1%
Other 8.8%