Violation of C standard detected by clang -fsanitize=undefined
with clang 19.1.7 on Fedora 41 x86-64.
* src/counterexample.c (si_bfs_free):
* src/files.c (prefix_map_free, add_prefix_map):
* src/fixits.c (fixit_cmp, fixit_free, fixits_register):
(expand_to_conflict, nonunifying_shift_path)
(search_state_free_children, search_state_free, ssb_free)
(ssb_hasher, ssb_comp, ssb_equals, visited_hasher)
(visited_comparator, ssb_append, unifying_example):
* src/lssi.c (lssi_free, lssi_hasher, lssi_comparator)
(shortest_path_from_start):
* src/parse-simulation.c (free_parse_state)
(parse_state_list_new, parser_pop):
* src/state-item.c (hash_pair_hasher, hash_pair_comparator)
(hash_pair_free, hash_pair_table_create):
Avoid undefined behavior in C, which does not allow you to cast a
function pointer to some other function type and then call it via
that other type. Instead, use functions with correct types
according to the C standard, and cast their parameters.
* src/getargs.c (xargmatch_fn): Return int const, not int, to
match what ARGMATCH_DEFINE_GROUP does. In all uses of
ARGMATCH_DEFINE_GROUP, say that they return int, to match
xargmatch_fn.
(FLAGS_ARGMATCH): Do not cast function pointer.
* src/parse-simulation.c (vc_derivation_list_append): New function.
* src/system.h (deconst): New static function.
* src/parse-gram.y, src/scan-gram.l: Do not cast c-ctype.h function
args to unsigned char unnecessarily.
* src/parse-gram.c: Regenerate.
Copyright-paperwork-exempt: yes
Reported by Frank Heckenbach.
https://lists.gnu.org/r/bug-bison/2022-07/msg00011.html
* bootstrap.conf: Use c_strtod, so that even in French locales "1.5"
is accepted, instead of "1,5".
* src/counterexample.c, src/state-item.c: Use xtime_t instead of
time_t, so that accuracy goes from seconds to nanoseconds.
( counterexample_init): Depend on cex.timeout rather than
$TIME_LIMIT.
* doc/bison.texi (%define Summary): Document cex.timeout.
We crashed when rules were given on YYEOF.
Reported by Han Zheng.
Fixes https://github.com/akimd/bison/issues/92.
* src/reader.c (check_and_convert_grammar): Make sure YYEOF is not
an nterm.
* tests/input.at (Rule for YYEOF): New.
When we use `b4_` or `m4_` somewhere in the input, it is escaped as
`b4@'_`/`m4@'_` so that the warning about unexpanded b4_foo/m4_foo
macros does not fire.
But in the case of muscles, the `@'` escape was not recognized, and an
assertion was triggered.
Reported by Han Zheng.
<https://github.com/akimd/bison/issues/91>
* src/muscle-tab.c (COMMON_DECODE): Handle `@'`.
* tests/skeletons.at (Suspicious sequences): Check that case.
Currently, occurrences of these identifiers in the user's input yield
spurious warnings.
To tell the difference between a legitimate m4_foo from the user, and
a bad m4_foo coming from a non-evaluated macro of a skeleton, escape
the user's identifiers as m4@'_foo. We already use @' as a special
sequence to be stripped from the skeleton's output.
See <https://lists.gnu.org/r/bug-bison/2021-10/msg00026.html> and
previous commit ("warnings: be less picky about occurrences of m4_/b4_
in the output").
* src/flex-scanner.h (OBSTACK_SGROW): New.
* src/output.c (output_escaped): Escape m4_ and b4_.
* src/scan-code.l: Likewise.
* src/system.h (obstack_escape): Likewise.
And rewrite as a function.
* tests/skeletons.at (Suspicious sequences): Make sure the user can
use m4_foo/b4_foo without spurious warnings.
* cfg.mk: Disable sc_indent as auto indent is too invasive for now.
Enable sc_prohibit_atoi_atof, except where we don't care.
* src/location.c, src/muscle-tab.c: Use strtol instead of atoi.
It is not available on HP-UX 11i.
Reported by Larkin Nickle <me@larbob.org>.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00012.html>
Gnulib provides no replacement, but anyway we should be using doubles,
since difftime uses doubles.
* bootstrap.conf: We want portability on stdtod.
* src/counterexample.c: Use double, not float, for time measurements.
The recent changes to comply with POSIX are breaking Automake's test
suite.
Reported by Kiyoshi Kanazawa.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00005.html>
To limit the impact of POSIX changes, bind them to $POSIXLY_CORRECT.
Suggested by Karl Berry.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00009.html>
The existing `maintainer-check-posix` Make target checks these
changes.
* src/getargs.h, src/getargs.c (set_yacc): New.
Use it.
* data/skeletons/bison.m4 (b4_posix_if): New.
* data/skeletons/yacc.c (b4_declare_yyerror_and_yylex): Use it.
* doc/bison.texi, tests/local.at: Adjust.
On Solaris, sed throws away the NUL bytes from the stream, even in C
locale. So instead of postprocessing bison's stderr to neutralize
changes in value of `argv[0]`, use an envvar to actually neutralize
variations of `argv[0]` during tests.
Reported by Dagobert Michelsen.
<https://lists.gnu.org/r/bug-bison/2021-08/msg00025.html>
* src/main.c (main): Change `argv[0]` if BISON_PROGRAM_NAME is
defined.
* tests/bison.in: No longer mess with stderr, just pass
the expected BISON_PROGRAM_NAME value.
Check in m4's output if there are sequences such as m4_foo or b4_foo,
which are probably resulting from incorrect m4 processing.
It actually already is useful:
- it caught a leaking b4_lac_if leaking from glr.c, where LAC is not
supported, hence b4_lac_if is not defined.
- it also caught references to location.hh in position.hh when
location.hh does not exist.
- while making "Code injection" robust to these new warnings (it is
its very purpose to let b4_canary pass unevaluated), I saw that it
did not check lalr1.d, and when adding lalr1.d, it revealed it did
underquote ocurrences of token value types.
* src/scan-skel.l (macro): New abbreviation.
Use it.
* data/skeletons/glr.c: Don't use b4_lac_if, we don't have it.
* data/skeletons/location.cc: Don't generate position.hh when we don't
generate location.hh.
* data/skeletons/d.m4 (b4_basic_symbol_constructor_define): Fix
underquotation.
* data/skeletons/bison.m4 (b4_canary): New.
* tests/input.at (Code injection): Use it, and check lalr1.d too.
We had:
```
-mbchar ...|\xF0[\x\90-\xBF]([\x80-\xBF]{2})|...
+mbchar ...|\xF0[\x90-\xBF]([\x80-\xBF]{2})|...
```
so a precise sequence that matches the incorrect regex can let NUL
bytes pass through, which triggers an assertion violation downstream.
It is a pity that Flex does not report an error for such input.
Reported by Ahcheong Lee <ahcheong.lee@gmail.com>.
<https://lists.gnu.org/r/bug-bison/2021-04/msg00003.html>
* src/scan-gram.l (mbchar): Fix the bad regex.
* tests/input.at (Invalid inputs): Check that case.
The right-shift added in c22902e360
("tables: fix handling for useless tokens") is incorrect. In
particular, we need to reset the "new" bits.
Reported by Balázs Scheidler.
https://github.com/akimd/bison/issues/74
* src/tables.c (pos_set_set): Fix the right-shift.
Don't repeatedly call malloc/free for each call to map_file_name.
* bootstrap.conf: We need hash-map.
* src/files.h, src/files.c (map_file_name): The caller must not free
the result.
Adjust callers.
(mapped_dir_prefix, spec_mapped_header_file): Remove.
* src/files.c
(map_file_name): Rename as...
(map_file_name_alloc): this.
(mapped_files, map_file_name, string_equals, string_hash, string_free):
New.
Applies the file name mapping before exporting it as a symbol. This
allows the symbols to correctly respect the --file-prefix-map command
line option.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
That change was started in Bison 3.4. The announcement for 3.7 stated
that in Bison 3.8 we would use *.gv by default.
* src/files.c (compute_output_file_names): spec_graph_file defaults
too *.gv.
* doc/bison.texi, examples/c++/calc++/local.mk, tests/output.at:
Adjust.
Its removal was annonced several times in NEWS (for Bison 3.5, 3.6, 3.7).
* data/skeletons/c.m4, data/skeletons/yacc.c: Remove support for YYPRINT.
* NEWS: Fix the mess introduced by the merge.
Document the removal of YYPRINT.
* doc/bison.texi (The YYPRINT Macro): Remove.
* src/main.c (main): When traces are enabled, display the Bison
version.
* tests/conflicts.at, tests/report.at, tests/sets.at:
Use AT_PACKAGE_VERSION (for package.m4) instead of post-processing the
output.
Three new commits:
commit 8358090292
Author: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed Jan 20 18:30:16 2021 -0800
c: port to HP-UX 11.23
commit 2c294c1325
Author: Vincent Imbimbo <vmi6@cornell.edu>
Date: Sat Jan 23 13:25:18 2021 -0500
cex: fix state-item pruning
commit c22902e360
Author: Akim Demaille <akim.demaille@gmail.com>
Date: Sat Jan 23 18:40:15 2021 +0100
tables: fix handling for useless tokens
In some rare conditions, the generated parser can be wrong when there
are useless tokens.
Reported by Balázs Scheidler.
https://github.com/akimd/bison/issues/72
Balázs managed to prove that the bug was introduced in
commit af1c6f973a
Author: Theophile Ranquet <ranquet@lrde.epita.fr>
Date: Tue Nov 13 10:38:49 2012 +0000
tables: use bitsets for a performance boost
Suggested by Yuri at
<http://lists.gnu.org/archive/html/bison-patches/2012-01/msg00000.html>.
The improvement is marginal for most grammars, but notable for large
grammars (e.g., PosgreSQL's postgre.y), and very large for the
sample.y grammar submitted by Yuri in
http://lists.gnu.org/archive/html/bison-patches/2012-01/msg00012.html.
Measured with --trace=time -fsyntax-only.
parser action tables postgre.y sample.y
Before 0,129 (44%) 37,095 (99%)
After 0,117 (42%) 5,046 (93%)
* src/tables.c (pos): Replace this set of integer coded as an unsorted
array of integers with...
(pos_set): this bitset.
which was implemented long ago, but that I installed only recently
(March 2019), first published in v3.3.90.
That patch introduces a bitset to represent a set of integers. It
managed negative integers by using a (fixed) base (the smallest
integer to represent). It avoided negative accesses into the bitset
by ignoring integers smaller than the base, under the asumption that
these cases correspond to useless tokens that are ignored anyway.
While it turns out to be true for all the test cases in the test suite
(!), Balázs' use case demonstrates that it is not always the case.
So we need to be able to accept negative integers that are smaller
than the current base.
"Amusingly" enough, the aforementioned patch was visibly unsure about
itself:
/* Store PLACE into POS_SET. PLACE might not belong to the set
of possible values for instance with useless tokens. It
would be more satisfying to eliminate the need for this
'if'. */
This commit needs several improvements in the future:
- support from bitset for bit assignment and shifts
- amortized resizing of pos_set
- test cases
* src/tables.c (pos_set_base, pos_set_dump, pos_set_set, pos_set_test):
New.
Use them instead of using bitset_set and bitset_test directly.
There were several bugs in pruning that would leave the state-item
graph in an inconsistent state which could cause crashes later on:
- Pruning now happens in one pass instead of two.
- Disabled state-items no longer prune the state-items they transition
to if that state-item has other states that transition to it.
- State-items that transition to disabled state-items are always
pruned even if they have productions.
Reported by Michal Bartkowiak <michal.bartkowiak@nokia.com>
https://lists.gnu.org/r/bug-bison/2021-01/msg00000.html
and Zartaj Majeed
https://github.com/akimd/bison/issues/71
* src/state-item.c (prune_forward, prune_backward): Fuse into...
(prune_state_item): this.
Adjust callers.
Currently each time we meet %merge we record this location as the
defining location (and symbol). Instead, record the first definition.
In the generated code we go from
yy0->A = merge (*yy0, *yy1);
to
yy0->S = merge (*yy0, *yy1);
where S was indeed the first symbol, and in the diagnostics we go from
glr-regr18.y:30.18-24: error: result type clash on merge function 'merge': <type2> != <type1>
30 | sym2: sym3 %merge<merge> { $$ = $1; } ;
| ^~~~~~~
glr-regr18.y:29.18-24: note: previous declaration
29 | sym1: sym2 %merge<merge> { $$ = $1; } ;
| ^~~~~~~
glr-regr18.y:31.13-19: error: result type clash on merge function 'merge': <type3> != <type2>
31 | sym3: %merge<merge> { $$ = 0; } ;
| ^~~~~~~
glr-regr18.y:30.18-24: note: previous declaration
30 | sym2: sym3 %merge<merge> { $$ = $1; } ;
| ^~~~~~~
to
glr-regr18.y:30.18-24: error: result type clash on merge function 'merge': <type2> != <type1>
30 | sym2: sym3 %merge<merge> { $$ = $1; } ;
| ^~~~~~~
glr-regr18.y:29.18-24: note: previous declaration
29 | sym1: sym2 %merge<merge> { $$ = $1; } ;
| ^~~~~~~
glr-regr18.y:31.13-19: error: result type clash on merge function 'merge': <type3> != <type1>
31 | sym3: %merge<merge> { $$ = 0; } ;
| ^~~~~~~
glr-regr18.y:29.18-24: note: previous declaration
29 | sym1: sym2 %merge<merge> { $$ = $1; } ;
| ^~~~~~~
where both duplicates are reported against definition 1, rather than
using definition 1 as a reference when diagnosing about definition 2,
and then 2 as a reference for 3.
* src/reader.c (record_merge_function_type): Keep the first definition.
* tests/glr-regression.at: Adjust.
Don't generate C code from bison, leave that to the skeletons.
* src/output.c (merger_output): Emit invocations to b4_call_merger.
* data/skeletons/glr.c (b4_call_merger): New.
Symbols are richer than types, and in M4 it is my simpler (and more
common) to deal with symbols rather than types. So let's associate
mergers to a symbol rather than a type name.
* src/reader.h (merger_list): Replace the 'type' member by a symbol
member.
* src/reader.c (record_merge_function_type): Take a symbol as
argument, rather than a type name.
* src/output.c (merger_output): Adjust.
This macro is not exposed to users, make start it with 'YY_'.
* data/skeletons/bison.m4, data/skeletons/c.m4, data/skeletons/glr.c,
* data/skeletons/glr.cc, data/skeletons/lalr1.cc,
* src/parse-gram.c, tests/actions.at, tests/c++.at, tests/headers.at,
* tests/local.at (YYUSE): Rename as...
(YY_USE): this.
