Hi Frank, Now to the core issue.
> Le 30 nov. 2019 à 06:52, Frank Heckenbach <[email protected]> a écrit : > > The first warning vanishes with g++-9, but it might be a real issue. > Though C[++] type promotion rules are still a horror to me, the > following test program seems to do what Bison does and yields "0" > (either compiler version, either compiled as C or C++) which > (assuming that's correct for C[++]) would indicate that Bison's > comparison is wrong. > > #include <stdio.h> > > int main () > { > enum { empty_state = -1 }; > unsigned char c = empty_state; > printf ("%i\n", c == empty_state); > } Thanks a lot for catching this! I believe the cure to be actually very simple. Here is my proposal. Cheers! commit d4a6c3c58ac085034858a0191ca7a814f737f024 Author: Akim Demaille <[email protected]> Date: Sat Dec 7 09:22:55 2019 +0100 c++: beware of short ranges for state numbers Now that we use small integral types, possibly unsigned (e.g., unsigned char), to store state numbers, using -1 to denote an empty state (i.e., a state that stores no semantical value) is very dangerous: it will be confused with state 255, which might be non-empty. Rather than allocating a larger range of state numbers to keep the empty-state apart, let's use the number of a state known to store no value. The initial state, numbered 0, seems to fit perfectly the job. Reported by Frank Heckenbach. https://lists.gnu.org/archive/html/bug-bison/2019-11/msg00016.html * data/skeletons/lalr1.cc (empty_state): Be 0. diff --git a/data/skeletons/lalr1.cc b/data/skeletons/lalr1.cc index 8a2bee04..71037a81 100644 --- a/data/skeletons/lalr1.cc +++ b/data/skeletons/lalr1.cc @@ -335,7 +335,8 @@ m4_define([b4_shared_declarations], symbol_number_type type_get () const YY_NOEXCEPT; /// The state number used to denote an empty symbol. - enum { empty_state = -1 }; + /// We use the initial state, as it does not have a value. + enum { empty_state = 0 }; /// The state. /// \a empty when empty.
