Re: Updating from bison 1.24 to 2.4.1

George Neuner <gneuner2@comcast.net>
Wed, 28 Jul 2010 12:59:00 -0400

          From comp.compilers

Related articles
Updating from bison 1.24 to 2.4.1 soeren.zimmermann@sef.de (Tuggi) (2010-07-23)
Re: Updating from bison 1.24 to 2.4.1 haberg-news@telia.com (Hans Aberg) (2010-07-25)
Re: Updating from bison 1.24 to 2.4.1 gneuner2@comcast.net (George Neuner) (2010-07-26)
Re: Updating from bison 1.24 to 2.4.1 gene.ressler@gmail.com (Gene) (2010-07-27)
Re: Updating from bison 1.24 to 2.4.1 gneuner2@comcast.net (George Neuner) (2010-07-28)
Re: Updating from bison 1.24 to 2.4.1 joeldenny@joeldenny.org (Joel E. Denny) (2010-07-29)
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Wed, 28 Jul 2010 12:59:00 -0400
Organization: A noiseless patient Spider
References: 10-07-029 10-07-032
Keywords: bison
Posted-Date: 28 Jul 2010 21:58:56 EDT

On Mon, 26 Jul 2010 12:18:04 -0400, George Neuner
<gneuner2@comcast.net> wrote:


>Since Bison found Reduce/Reduce conflicts, it would have returned an
>error code so that make (or whatever build system you use) knew to
>stop the build. [Nope. See below. -John]
> :
>[As the prior message noted, bison produces a parser even if there are
>reduce/reduce errors, by using the rule that appears first in the source
>file. I agree that fixing the conflicts would be a good idea. -John]


John is correct that a reduce/reduce problem, while a symptom of a
broken LALR grammar, won't normally stop bison from producing a
parser.


However ...


bison always has returned a result code to the shell. In accordance
with Unix tradition, a zero code indicated all was well while a
non-zero code indicated a fatal error - i.e., one that prevented
generating a parser. Syntax errors in the grammar, file errors, fork
or pipe errors (since M4), etc., would cause such an error exit. This
was and is true of *all* bison versions.


But bison did not signal that a grammar had warnings - it only
returned non-zero if it was unable to generate a parser. If you
wanted to stop a build on warnings you had to catch bison's console
output and grep for them.


Enter bison v2.4, which introduced a new command line option:
"--warnings=error", which the documentation says is supposed to cause
bison to treat any warning as an error and cause an error exit if any
warnings are generated. "--warnings=none" suppresses warnings. There
are a few other flags as well.


Now I had never tried using "--warnings", and now I have come to find
out that it doesn't work. bison 2.4.1 - the 2.4._ I have available -
recognizes the option syntax, but none of the flags I tried appeared
to have any effect.


Oh well. Here's hoping it works in 2.4.2. Nothing about it in the
change log though :( Since M4 entered the picture, building bison is
a painful chore ... I'll do it if I have to, but I'd rather find
prebuilt 2.4.2 binaries for Ubuntu or Windows. Anybody?


George



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.