Akim Demaille <[EMAIL PROTECTED]> writes: > So, what is our attitude? If we start worrying about such bugs, > we might as well document it in the FAQ. Or we can have configure > issue a warning stating that > > W.L. Estes doesn't care about generating code for pre-C99, > so examples/calc++ is likely to fail > > ? Or be robust to that bug?
The bug is in the code that flex generates; it has nothing to do with how we use the code. It's not clear to me how Bison could work around the bug in general. I have documented the problem in the Bison manual, as follows: http://lists.gnu.org/archive/html/bison-patches/2006-02/msg00035.html Hmm, I now see the bug is still in flex 2.5.33 so I installed this change: 2006-05-11 Paul Eggert <[EMAIL PROTECTED]> * doc/bison.texinfo (Calc++ Scanner): The flex behavior is an incompatibility, not a bug. Mention that it wasn't fixed as of flex 2.5.33. --- doc/bison.texinfo 9 May 2006 06:40:13 -0000 1.186 +++ doc/bison.texinfo 11 May 2006 16:53:40 -0000 @@ -7583,10 +7583,14 @@ parser's to get the set of defined token # include <string> # include "calc++-driver.hh" # include "calc++-parser.hh" -/* Work around a bug in flex 2.5.31. See Debian bug 333231 - <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333231>. */ + +/* Work around an incompatibility in flex (at least versions + 2.5.31 through 2.5.33): it generates code that does + not conform to C89. See Debian bug 333231 + <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333231>. */ # undef yywrap # define yywrap() 1 + /* By default yylex returns int, we use token_type. Unfortunately yyterminate by default returns 0, which is not of token_type. */
