This is not only cleaner, it also protects us from mixing signed
values (YYEMPTY is #defined as -2) with unsigned types (the
yysymbol_type_t enum is typically compiled as a small unsigned).
For instance GCC 9:
input.c: In function 'yyparse':
input.c:1107:7: error: conversion to 'unsigned int' from 'int'
may change the sign of the result
[-Werror=sign-conversion]
1107 | yyn += yytoken;
| ^~
input.c:1107:10: error: conversion to 'int' from 'unsigned int'
may change the sign of the result
[-Werror=sign-conversion]
1107 | yyn += yytoken;
| ^~~~~~~
input.c:1108:47: error: comparison of integer expressions of
different signedness:
'yytype_int8' {aka 'const signed char'} and
'yysymbol_type_t' {aka 'enum yysymbol_type_t'}
[-Werror=sign-compare]
1108 | if (yyn < 0 || YYLAST < yyn || yycheck[yyn] != yytoken)
| ^~
input.c:702:25: error: operand of ?: changes signedness from 'int'
to 'unsigned int' due to unsignedness of
other operand [-Werror=sign-compare]
702 | #define YYEMPTY (-2)
| ^~~~
input.c:1220:33: note: in expansion of macro 'YYEMPTY'
1220 | yytoken = yychar == YYEMPTY ? YYEMPTY : YYTRANSLATE (yychar);
| ^~~~~~~
input.c:1220:41: error: unsigned conversion from 'int' to
'unsigned int' changes value
from '-2' to '4294967294'
[-Werror=sign-conversion]
1220 | yytoken = yychar == YYEMPTY ? YYEMPTY : YYTRANSLATE (yychar);
| ^
Eventually, it might be interesting to move away from -2 (which is the
only possible negative symbol number) and use the next available
number, to save bits. We could actually even simply use "0" and shift
the rest, which would allow to write "!yytoken" to mean really
"yytoken != YYEMPTY".
* data/skeletons/c.m4 (b4_declare_symbol_enum): Define YYSYMBOL_YYEMPTY.
* data/skeletons/yacc.c: Use it.
* src/parse-gram.y (yyreport_syntax_error): Use YYSYMBOL_YYEMPTY, not
YYEMPTY, when dealing with a symbol.
* tests/regression.at: Adjust.
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 is 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.
Running a non installed bison
Once you ran make, you might want to toy with this fresh bison before
installing it. In that case, do not use src/bison: it would use the
installed files (skeletons, etc.), not the local ones. Use tests/bison.
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/pub/gnu/gettext/libtextstyle-0.20.5.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.