gmane.comp.parsers.bison.bugs

bison-2.5.1_rc2 released [beta]

Akim Demaille — 2012-05-25T17:19:31

The Bison team is very happy to announce the forthcoming release
of Bison 2.5.1, which addresses quite a few issues from Bison 2.5.

Here are the compressed sources:
 ftp://alpha.gnu.org/gnu/bison/bison-2.5.1_rc2.tar.gz   (2.7MB)
 ftp://alpha.gnu.org/gnu/bison/bison-2.5.1_rc2.tar.xz   (1.5MB)

Here are the GPG detached signatures[*]:
 ftp://alpha.gnu.org/gnu/bison/bison-2.5.1_rc2.tar.gz.sig
 ftp://alpha.gnu.org/gnu/bison/bison-2.5.1_rc2.tar.xz.sig

Use a mirror for higher download bandwidth:
 http://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

 gpg --verify bison-2.5.1_rc2.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

 gpg --keyserver keys.gnupg.net --recv-keys 78D5264E

and rerun the 'gpg --verify' command.

This release was bootstrapped with the fol

Building bison from master fails: "conflicting types for'code_get_leng'"

Stefano Lattarini — 2012-05-13T10:46:59

When I try to bootstrap and build bison from latest master on my Debian
system, I see this failure:

  ...
  CC       src/src_bison-reduce.o
  CC       src/src_bison-relation.o
  CC       src/src_bison-scan-code-c.o
In file included from src/scan-code-c.c:3:0:
src/scan-code.c:789:11: error: conflicting types for 'code_get_leng'
./src/flex-scanner.h:28:1: note: previous declaration of 'code_get_leng' was here
In file included from src/scan-code-c.c:3:0:
src/scan-code.c:2344:11: error: conflicting types for 'code_get_leng'
./src/flex-scanner.h:28:1: note: previous declaration of 'code_get_leng' was here
Makefile:3833: recipe for target 'src/src_bison-scan-code-c.o' failed
make[2]: *** [src/src_bison-scan-code-c.o] Error 1

Attached is the config.log.  I'm using Automake and Autoconf from master, and
flex 2.5.36.  Let me know if you need more information.

Regards,
  Stefano

nuke strncpy

Jim Meyering — 2012-05-03T21:18:28

I noticed that there were some unnecessary uses of strncpy in bison.
The first patch removes them.
Along the way I noticed a 3-line xmalloc+memcpy+zero-one-byte sequence
that can be replaced by a single-line xstrdup use.  That's #2.
And #3 merely regenerates parse-gram.[ch].

[PATCH 1/3] maint: s/strncpy/memcpy/, when equivalent
[PATCH 2/3] maint: simplify parse-gram.y
[PATCH 3/3] maint: regen src/parse-gram.[ch]

Use "git" instead of "CVS" in the description of the bison-patchesmailing list

Stefano Lattarini — 2012-04-01T19:35:01

In the mailing list description here:

  <https://lists.gnu.org/mailman/listinfo/bison-patches>

I read:

  ``If you have found a bug in Bison, or have made an improvement, please
    send a patch, made for the CVS sources, to this mailing list.''

But bison doesn't use CVS anymore (thanks $DEITY :-) so that a correct
description should refer to the "git sources" or "git repository" (and
a link to said repository wouldn0t hurt either, IMHO).

Regards,
  Stefano

[PATCH] master: Doxygen generation broken

Tim Landscheidt — 2012-03-27T22:41:28

Hi,

the transition from recursive makefiles to the present ones
broke Doxygen generation.  The first attached patch fixes
this.

  Then running Doxygen 1.6.1 gave some warnings about obso-
lete options in Doxyfile that don't seem to be important.
Also, Doxygen complained about not being able to find header
files.  First I thought that these were gnulib's, so I added
lib to the INCLUDE_PATH, but Doxygen kept complaining even
about system header files like stddef.h included with angle
brackets, so I ignored it.

  Finally, it revealed a small typo in a Doxygen comment in
src/InadequacyList.h which the other attached patch fixes.

Tim

Bugs at Savannah

Tim Landscheidt — 2012-03-23T20:41:55

Hi,

with 2.5.1 on the horizon, a look at the remaining bugs on
Savannah (https://savannah.gnu.org/support/?group=bison):

- "Testcase #50 failing non-deterministically for bison
  2.4": I assume this was fixed by 47fa57; at least
  lib/subpipe.c is gone anyway :-).

- "Updating to bison 2.4 breaks WebKit": This seems to have
  been a duplicate of
  http://permalink.gmane.org/gmane.comp.parsers.bison.bugs/3078
  and solved on WebKit's side per
  https://bugs.webkit.org/show_bug.cgi?id=22205.

- "YYPOPSTACK used inconsistently": The user infers from
  yacc.c to "garbage collected environments".  The code in
  lalr1.cc looks fine.

- "--no-parser and %no-parser option is broken": Probably
  "Wont Do".

- "ambiguity problem with bison GLR parser": The reporter
  initially misread the manual.

- "Possible bug in overflow handling": After staring for
  half an hour at yacc.c's code paths, I think this is not a
  bug (and hope that saving a few bytes is really worth the
  very "special" memory management Bison use

[GNU Bison 2.5] testsuite: 229 232 failed

gccbison — 2012-03-13T15:54:39

229: GNU Cim Grammar: Canonical LR(1)                FAILED 
(existing.at:780)
232: GNU pic (Groff 1.18.1) Grammar: Canonical LR(1) FAILED 
(existing.at:1400)
cc1plus: warning: command line option '-Wbad-function-cast' is valid 
for C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option '-Wmissing-prototypes' is valid 
for Ada/C/ObjC but not for C++ [enabled by default]
cc1plus: warning: command line option '-Wstrict-prototypes' is valid 
for Ada/C/ObjC but not for C++ [enabled by default]
and multiple of these errors:
input.y:224:7: error: line number out of range [-Werror]
Using gcc (GCC) 4.8.0 20120311 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
[GNU Bison 2.5] testsuite: 229 232 failed
Not sure if this a Bison or GCC issue

help

Aravind Thangavel — 2012-03-09T04:53:37

i'm trying to compile a really old c++ code. In which there is a bison
command

bison -d -b exp  -t exp.yacc

generating a file

exp.tab.cacc
exp.tab.hacc

But the next command is this

mv exp.tab.c exp.tab.cc

Generating an error exp.tab.c does not exists.

So what is the solution?

[GNU Bison 2.5] testsuite: 247 failed

Martin & Dunja Zaun — 2012-03-07T03:45:07

$ uname -a
SunOS hoops-s11 5.11 11.0 i86pc i386 i86pc

$ gcc --version
gcc (GCC) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ autoconf --version
autoconf (GNU Autoconf) 2.63
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

"Syntax error before ," in generated .c file

Gizmotechspert — 2012-03-05T13:49:53

dict_parser.c:1068: error: syntax error before ',' token

Generated code:
1065   /* YYCHAR is either YYEMPTY or YYEOF or a valid lookahead symbol.  */
1066   if (yychar == YYEMPTY)
1067     {
1068       YYDPRINTF ((stderr, "Reading a token: "));
1069       yychar = YYLEX;
1070     }

The variable YYDPRINTF is defined and it isn't supposed to throw a syntax
error at this place. No clue what's going wrong or how to fix this issue.

[GNU Bison 2.5] testsuite: 3 4 7 8 16 21 33 36 45 68 69 70 92 93 9495 139 143 145 151 160 220 221 222 228 233 246 failed

Lie Yan — 2012-03-02T12:52:57

master: Dependencies broken

Tim Landscheidt — 2012-02-23T15:18:07

Hi,

on a freshly cloned and bootstrapped copy:

| [tim< at >passepartout ~/src/bison]$ make
|   GEN    examples/calc++/calc.stamp
| extexi: ignoring rpcalc.y
| extexi: ignoring mfcalc.y
| extexi: ignoring calc.h
| extexi: extracting calc++-driver.hh
| extexi: extracting calc++-driver.cc
| extexi: extracting calc++-parser.yy
| extexi: extracting calc++-scanner.ll
| extexi: extracting calc++.cc
|   GEN    examples/calc++/calc++-scanner.ll
| make: *** Keine Regel vorhanden, um das Target »examples/calc++/stack.hh«,
|   benötigt von »all«, zu erstellen.  Schluss.
| [tim< at >passepartout ~/src/bison]$

Continuing ignorantly:

| [tim< at >passepartout ~/src/bison]$ make -k
| make: *** Keine Regel vorhanden, um das Target »examples/calc++/stack.hh«,
|   benötigt von »all«, zu erstellen.
| make: *** Keine Regel vorhanden, um das Target »examples/calc++/position.hh«,
|   benötigt von »all«, zu erstellen.
| make: *** Keine Regel vorhanden, um das Target »examples/calc++/location.hh«,
|   benötigt von »all«, zu

GLR: ambiguity reports are wrong

Akim Demaille — 2012-02-21T11:20:46

On this grammar:


with input a b c d, the current code reports:


instead of:


This is a regression I introduced in master only with
commit 783aa653f4ca70a75919c8516b950494c612cbfe.
http://lists.gnu.org/archive/html/bison-patches/2008-11/msg00291.html

new test failures

Jim Meyering — 2012-02-17T07:53:45

Hi Akim,

It looks like you're adding tests, and once I got past
the link failure (missing -lm) I see they're failing.
Presuming you're still working there, I'll simply
post the test-suite.log file:

====================================================
   GNU Bison 2.4.669-c119-dirty: ./test-suite.log
====================================================

# TOTAL: 2
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: examples/calc++/test
==========================

--(end of buffer or a NUL)
--accepting rule at line 46 ("1")
--accepting rule at line 39 ("+")
--accepting rule at line 46 ("2")
--accepting rule at line 40 ("*")
--accepting rule at line 46 ("3")
--accepting rule at line 36 ("
")
--accepting rule at line 54 ("=")
2.1: invalid character
--accepting rule at line 35 (" ")
--accepting rule at line 46 ("1")
2.3: syntax error, unexpected number, expecting end of file
test: FAIL:  1 (expected status: 0, effective: 1
1.1: syntax error, unexpected end of file,

[PATCH] examples: link mfcalc with -lm for uses of pow, cos, atan,etc.

Jim Meyering — 2012-02-17T07:37:56

Building from cloned sources, I got this:

...
gcc -std=gnu99 -Wall -Wextra -Wno-sign-compare -Wcast-align -Wcast-qual -Wformat
-Wpointer-arith -Wwrite-strings -Wbad-function-cast -Wmissing-declarations -Wmiss
ing-prototypes -Wshadow -Wstrict-prototypes -g -O2   -o examples/mfcalc/mfcalc ex
amples/mfcalc/examples_mfcalc_mfcalc-mfcalc.o lib/libbison.a
examples/mfcalc/examples_mfcalc_mfcalc-mfcalc.o: In function `yyparse':
/h/j/w/co/bison/../../doc/bison.texinfo:2419: undefined reference to `pow'
examples/mfcalc/examples_mfcalc_mfcalc-mfcalc.o:(.rodata+0x88): undefined reference to `atan'
examples/mfcalc/examples_mfcalc_mfcalc-mfcalc.o:(.rodata+0x98): undefined reference to `cos'
examples/mfcalc/examples_mfcalc_mfcalc-mfcalc.o:(.rodata+0xa8): undefined reference to `exp'
examples/mfcalc/examples_mfcalc_mfcalc-mfcalc.o:(.rodata+0xb8): undefined reference to `log'
examples/mfcalc/examples_mfcalc_mfcalc-mfcalc.o:(.rodata+0xc8): undefined reference to `sin'
examples/mfcalc/examples_mfcalc_mfcalc-mfcalc.o:(.rodata+

[PATCH] tests: avoid c++ failure due to lack of getenv decl

Jim Meyering — 2012-02-16T10:11:12

I noticed that there was a single test failure when
running "make check" using the latest gcc/g++ from git (4.7.x).

Pushed to master, as obvious:

From 292402a9b2a9fe3440008e42a41b01185d9a4f9d Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering< at >redhat.com>
Date: Thu, 16 Feb 2012 11:03:31 +0100
Subject: [PATCH] tests: avoid c++ failure due to lack of getenv decl

* tests/c++.at (Syntax error as exception): Avoid spurious failure
at least when compiling with g++-4.7.x due to lack of declaration
of getenv.  Include <stdlib.h>.
---
 tests/c++.at |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/c++.at b/tests/c++.at
index d29b6f6..3510498 100644
--- a/tests/c++.at
+++ b/tests/c++.at
< at >< at > -461,6 +461,7 < at >< at > AT_DATA_GRAMMAR([[input.yy]],

 %code
 {
+  #include <stdlib.h>
   int yylex (yy::parser::semantic_type *);
 }

< at >< at > -510,7 +511,7 < at >< at > yy::parser::error (const std::string &m)
 }

 int
-main ()
+main (void)
 {
   yy::parser parser;
   parser.set_debug_level(!!getenv("YYDEBUG"));
--
1.7

master: bootstrap doesn't clean up properly

Tim Landscheidt — 2012-02-11T17:50:38

Hi,

on a freshly cloned copy, after "git submodule update --init
&& ./bootstrap && ./configure && make && make check", "git
status" gives:

| # On branch master
| # Untracked files:
| #   (use "git add <file>..." to include in what will be committed)
| #
| #build-aux/config.rpath~
| #build-aux/snippet/
| #lib/glthread/
| #m4/codeset.m4~
| #m4/fcntl-o.m4~
| #m4/gettext.m4~
| #m4/glibc2.m4
| #m4/glibc2.m4~
| #m4/glibc21.m4~
| #m4/iconv.m4~
| #m4/intdiv0.m4
| #m4/intdiv0.m4~
| #m4/intl.m4
| #m4/intl.m4~
| #m4/intldir.m4
| #m4/intldir.m4~
| #m4/intlmacosx.m4~
| #m4/intmax.m4
| #m4/intmax.m4~
| #m4/inttypes-pri.m4~
| #m4/inttypes_h.m4~
| #m4/lcmessage.m4
| #m4/lcmessage.m4~
| #m4/lib-ld.m4~
| #m4/lib-link.m4~
| #m4/lib-prefix.m4~
| #m4/lock.m4
| #m4/lock.m4~
| #m4/longlong.m4~
| #m4/nls.m4~
| #m4/po.m4~
| #m4/printf-posix.m4~
| #m4/progtest.m4~
| #m4/size_max.m4~
| #m4/stdint_h.m4~
| #m4/threadlib.m4~
| #m4/uintmax_t.m4
| #m4/uintmax_t.m4~
| #m4/visibility.m4
| #m4/visibil

"check" table missing comment in bison.m4

Tim Landscheidt — 2012-02-11T01:18:56

Hi,

the "check" table (yycheck_[] in the Java incarnation) has
no comment in bison.m4's b4_integral_parser_tables_map which
leads to a misindentation in the generated Java scanner:

| [...]

| /* YYTABLE[YYPACT[STATE-NUM]].  What to do in state STATE-NUM.  If
|    positive, shift that token.  If negative, reduce the rule which
|    number is the opposite.  If YYTABLE_NINF, syntax error.  */
|   private static final byte yytable_[] = yytable_init();
|   private static final byte[] yytable_init()
|   {
| [...]
|   }

| private static final byte yycheck_[] = yycheck_init();
|   private static final byte[] yycheck_init()
|   {
| [...]
|   }

| /* STOS_[STATE-NUM] -- The (internal number of the) accessing
|    symbol of state STATE-NUM.  */
|   private static final byte yystos_[] = yystos_init();
|   private static final byte[] yystos_init()
|   {
| [...]

Rather than accounting for tables without a comment, I think
it'd be much easier to just document the table :-).

Tim

[PATCH] maint: force "make syntax-check" to pass by skipping failingtests

Jim Meyering — 2012-01-29T20:27:54

There are a few failing syntax-check tests.
For now, I propose to simply skip them.
If folks have time/desire to address the issues
or exempt the offending files, these tests can
easily be reenabled later.

I've just addressed the sole violation of the m4 quote check
in the 2nd patch below:

From bffa42b866e7d4b2d6257904679d77b905ab5fca Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering< at >redhat.com>
Date: Sat, 28 Jan 2012 17:11:43 +0100
Subject: [PATCH 1/2] maint: force "make syntax-check" to pass by skipping
 failing tests

* cfg.mk (local-checks-to-skip): Skip all currently-failing tests.
Remove changelog-check; it's long gone.
---
 cfg.mk |   24 ++++++++++++++++++------
 1 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/cfg.mk b/cfg.mk
index 6b3deb9..2a4d711 100644
--- a/cfg.mk
+++ b/cfg.mk
< at >< at > -33,12 +33,24 < at >< at > url_dir_list = \
   ftp://$(gnu_rel_host)/gnu/bison

 # Tests not to run as part of "make distcheck".
-# Exclude changelog-check here so that there's less churn in ChangeLog
-# files

[PATCH] do not ignore errors like ENOSPC,EIO when writing to stdout

Jim Meyering — 2012-01-29T18:22:57

This is incomplete in that I haven't added a test for it
and haven't updated NEWS -- since its effect is limited,
I'm not sure it's worthy of a NEWS entry.

Before:

    $ bison --print-datadir > /dev/full
    $ bison --print-datadir >&-
    $

After:

    $ bison --print-datadir > /dev/full
    bison: write error: No space left on device
    [Exit 1]
    $ bison --print-datadir >&-
    bison: write error: Bad file descriptor
    [Exit 1]
    $

From 581dfdb383842aced19443db6f910fbd02736e23 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering< at >redhat.com>
Date: Sun, 29 Jan 2012 12:50:32 +0100
Subject: [PATCH] do not ignore errors like ENOSPC,EIO when writing to stdout

Standard output was never explicitly closed, so we could not
detect failure.  Thus, bison would ignore the errors of writing
to a full file system and getting an I/O error on write, but only
for standard output, e.g., for --print-localedir, --print-datadir,
--help and some verbose output.
Now, "bison --print-datadir > /dev/full" reports the wr

[GNU Bison 2.5] testsuite: 247 failed on Solaris 10 on SPARC(sun4v)

Tomohiro Suzuki — 2012-01-24T06:50:19

Hi, I'm getting a "make check" failure on bison-2.5.
bison-2.4.3 doesn't have the problem.

OS:Solaris 10 on SPARC(sun4v)

I attach the testsuite.log and config.log.

-----
# uname -a
SunOS moore 5.10 Generic_147440-04 sun4v sparc SUNW,SPARC-Enterprise-T1000

# /usr/local/bin/gcc --version
gcc (GCC) 4.2.4
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# make check
.....
Regression tests.

223: Trivial grammars                                ok
224: YYSTYPE typedef                                 ok
225: Early token definitions with --yacc             ok
226: Early token definitions without --yacc          ok
227: Braces parsing                                  ok
228: Duplicate string                                ok
229: Rule Line Numbers                               ok
230: Mixing %token styles                            ok
231: Invalid inputs