[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bison-2.1 compilation warnings

From: Paul Eggert
Subject: Re: bison-2.1 compilation warnings
Date: Thu, 11 May 2006 09:57:10 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

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:


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]