Re: bison-2.1 compilation warnings

[Paul Eggert]

Akim Demaille <address@hidden> 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  <address@hidden>

        * 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.  */