gmane.comp.parsers.bison.bugs

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

Akim Demaille — 2012-05-16T09:07:22

Le 16 mai 2012 à 10:54, Stefano Lattarini a écrit :


Really, did you start from a fresh clone?  There are very nasty
issues, such as dangling symlink for *.m4 files that breaks
aclocal.  Be sure to, at least, git clean -fr.  Or just
rm -rf in your bison directory and check out again.

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

Stefano Lattarini — 2012-05-16T08:54:31

Sorry, I've been unclear; I meant: the *bootstrap* itself fails like this:


  Don't forget to
    - "include gnulib.mk" from within "lib/Makefile.am",
    - mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am,
    - mention "m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am,
    - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC_STDC,
    - invoke gl_INIT in ./configure.ac.
  running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install \
                                                     --no-recursive -I m4
  autoreconf2.50: Entering directory `.'
  autoreconf2.50: running: true
  autoreconf2.50: running: aclocal -I m4 -I m4
  autoreconf2.50: configure.ac: tracing
  autoreconf2.50: configure.ac: not using Libtool
  autoreconf2.50: running: /usr/bin/autoconf --include=m4
  configure.ac:122: error: possibly undefined macro: AC_PROG_GNU_M4
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
  autoreconf2.50: /usr/bin/autoconf fail

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

Akim Demaille — 2012-05-16T08:34:56

Le 15 mai 2012 à 22:45, Stefano Lattarini a écrit :


No :(  That's really weird.  Could you please provide me
with one of the wrong generated scanner?  Maybe there's
something wrong in the macros that define the version?

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

Stefano Lattarini — 2012-05-15T20:45:44

OK, I've re-done the check applying the patch to the top of maint, but I
see the same exact error as before.  Any clue?

Regards,
  Stefano

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

Akim Demaille — 2012-05-15T17:28:57

Le 15 mai 2012 à 18:19, Stefano Lattarini  
<stefano.lattarini< at >gmail.com> a écrit :


Next is on top of maint, and I guess you
had checked out master.  This is a case
where bootstrap behaves very badly and
you get all sorts of failures.

I should have told you this is not master,
sorry :/

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

Stefano Lattarini — 2012-05-15T16:19:04

And right after it has failed, I get:

  $ git diff
  diff --git a/m4/m4.m4 b/m4/m4.m4
  deleted file mode 120000
  index 5b176ba..0000000
  --- a/m4/m4.m4
  +++ /dev/null
  < at >< at > -1 +0,0 < at >< at >
  -../submodules/autoconf/m4/m4.m4
  \ No newline at end of file

Regards,
  Stefano

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

Stefano Lattarini — 2012-05-15T15:59:42

Bootstrapping the 'next' branch fails for me with:

  Don't forget to
    - "include gnulib.mk" from within "lib/Makefile.am",
    - mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am,
    - mention "m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am,
    - invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC_STDC,
    - invoke gl_INIT in ./configure.ac.
  running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install \
                                                     --no-recursive -I m4
  autoreconf2.50: Entering directory `.'
  autoreconf2.50: running: true
  autoreconf2.50: running: aclocal -I m4 -I m4
  autoreconf2.50: configure.ac: tracing
  autoreconf2.50: configure.ac: not using Libtool
  autoreconf2.50: running: /usr/bin/autoconf --include=m4
  configure.ac:122: error: possibly undefined macro: AC_PROG_GNU_M4
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
  autoreconf2.50: /usr/bin/autoconf failed with exit status: 1

T

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

Akim Demaille — 2012-05-15T09:23:52

Le 14 mai 2012 à 23:11, Stefano Lattarini a écrit :


So I guess this is a modified 2.5.35, as I have:

int code_get_leng (void );

Great...



Could you please try the attached patch?  Also in the
branch "next" at the moment.

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

Stefano Lattarini — 2012-05-14T21:11:50

Basically, it was a version of flex built from its development branch.
But the error persists also with flex 2.5.35 (installed from a Debian
package).


From 'src/scan-code.c':

    220:typedef size_t yy_size_t;
    ...
    679:#define FLEX_PREFIX(Id) code_ ## Id
    680:#include <src/flex-scanner.h>
    ...
    789:yy_size_t code_get_leng (void );

From 'src/flex-scanner.h':

    28:int   FLEX_PREFIX (get_leng) (void);

HTH,
  Stefano

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

Akim Demaille — 2012-05-14T12:01:10

Le 13 mai 2012 à 12:46, Stefano Lattarini a écrit :


Hi Stefano,

Thanks for the report.  As far as I know there is no
such things as Flex 2.5.36.  Where does it come from?
Could you provide me with the conflicted types?

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

Re: [PATCH 2/3] maint: simplify parse-gram.y

Akim Demaille — 2012-05-09T08:02:16

Le 6 mai 2012 à 11:27, Jim Meyering a écrit :


And I guess the git rebase has restored younger mtimes
to the generated files after you modified the source one.


Why not.  I kinda like the current setting, which avoids commits
which just change minor things (say the version of the bison
version that was used) in the generated files by leaving this in
the hands of the maintainers.  So if we find a means to avoid
gratuitous commits, I'm fine with this.

Bison uses itself to compile itself, via the test wrapper in
tests/.  We could extend it to ignore such minor differences.

Re: [PATCH 2/3] maint: simplify parse-gram.y

Jim Meyering — 2012-05-06T09:27:33

Ahh... my bad.  I merely rebased the 2nd of those 3 commits.
I should have manually ensured that those files were regenerated.

I'm not used to having generated files under version control.
IMHO, the fact that I ran "make distcheck" (and it did not
regenerate those .[ch] files) means that there is room for
improvement.

What do you think about making "make distcheck" ensure that using
the just-built bison induces no significant change in parse-gram.c?

Re: [PATCH 2/3] maint: simplify parse-gram.y

Akim Demaille — 2012-05-06T08:45:03

Le 6 mai 2012 à 09:31, Jim Meyering a écrit :


FTR, I have installed this.  Your regen step did not
use xmemdup0 for some reason, so the generated code
works, but breaks on the next regeneration.

From e54ec80c0c163e7a9e24fc2eee6c42a61cbe4316 Mon Sep 17 00:00:00 2001
From: Akim Demaille <akim< at >lrde.epita.fr>
Date: Sun, 6 May 2012 10:20:43 +0200
Subject: [PATCH 4/6] maint: import the xmemdup0 gnulib module.

* bootstrap.conf: Require this module.
* src/parse-gram.y: Include xmemdup0.h.
---
 bootstrap.conf   |    3 ++-
 lib/.gitignore   |    2 ++
 src/parse-gram.y |    1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/bootstrap.conf b/bootstrap.conf
index e1fd548..3303ef3 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
< at >< at > -26,7 +26,8 < at >< at > gnulib_modules='
   quote quotearg realloc-posix
   spawn-pipe stdbool stpcpy strdup-posix strerror strtoul strverscmp
   unistd unistd-safer unlocked-io update-copyright unsetenv verify
-  warnings xalloc xalloc-die xstrndup
+  warnings
+  xalloc xalloc-di

Re: [PATCH 2/3] maint: simplify parse-gram.y

Jim Meyering — 2012-05-06T07:31:16

Precisely.


Hah!  That's even better.
It's not often that one can replace so many lines with just one.

Pushed.

Re: [PATCH 2/3] maint: simplify parse-gram.y

Akim Demaille — 2012-05-06T06:58:00

Hi Jim!

This is perfect, push whenever you want.

Le 5 mai 2012 à 15:26, Jim Meyering a écrit :


For my education, you prefer memdup to strndup because of
of the inner strnlen of the latter, right?  It makes plenty
of sense, but this split memdup + '=0' is not nice looking.
It would be cleaner to have say xmemdup0 which would add
this 0.

Actually, I just grepped xmemdup in gnulib to see if there
are many such memdup + '=0', and here is what I found:

lib/xmemdup0.c:
char *
xmemdup0 (void const *p, size_t s)
{
  char *result = xcharalloc (s + 1);
  memcpy (result, p, s);
  result[s] = 0;
  return result;
}

:)  So please, make it

    {
      char *name = xmemdup0 (name_start, strspn (name_start, alphanum));
      muscle_pair_list_grow (type, decl, name);
      free (name);
    }

(I think this is the last time I will bug you with this patch :)
but looking at the surrounding code, I see that we do not support
\n in %parse-param, which is not nice, I will make another patch
on top of yours).

Re: [PATCH 2/3] maint: simplify parse-gram.y

Jim Meyering — 2012-05-05T13:26:16

Fixing that and applying your suggestion to use strspn in 2/2
and rebasing to maint, I get the following.  Will push later today.

From 121474cea7f26a27130f8f66b8dba8dc3e5ff52d Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering< at >redhat.com>
Date: Sat, 5 May 2012 11:30:01 +0200
Subject: [PATCH 1/2] maint: s/strncpy/memcpy/, when equivalent

* src/output.c (output_skeleton): Use memcpy, not strncpy,
since the source is known to fit in the destination buffer.
* src/parse-gram.y (%skeleton): Likewise.
---
 src/output.c     | 2 +-
 src/parse-gram.y | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/output.c b/src/output.c
index c481e14..e0d6ed3 100644
--- a/src/output.c
+++ b/src/output.c
< at >< at > -512,7 +512,7 < at >< at > output_skeleton (void)
   full_skeleton = xmalloc (pkgdatadirlen + 1
    + (skeleton_size < sizeof m4sugar
       ? sizeof m4sugar : skeleton_size));
-  strncpy (full_skeleton, pkgdatadir, pkgdatadirlen);
+  memcpy (full_skeleton, pkgdatadir, pkgdatadirlen);
   full_skeleton[p

Re: [PATCH 2/3] maint: simplify parse-gram.y

Jim Meyering — 2012-05-04T17:07:25

Oh!  Good catch.  I'll fix it to use this:

    name = xmemdup (name_start, name_len);


Good idea.  That will be much more readable.

Re: [PATCH 2/3] maint: simplify parse-gram.y

Akim Demaille — 2012-05-04T06:27:21

Hi Jim!

Thanks for the fixes, please install (in the maint branch
preferably).  Beware that this patch (2/3) already includes
a parse-gram.c regen part that should be part of 3/3.  Also:

Le 3 mai 2012 à 23:18, Jim Meyering a écrit :


This does not seem right: you no longer take name_len
into account.  The full context is:

 {
   char *name;
   size_t name_len;

   for (name_len = 1;
        memchr (alphanum, name_start[name_len], sizeof alphanum);
        name_len++)
     continue;

   name = xmalloc (name_len + 1);
   memcpy (name, name_start, name_len);
   name[name_len] = '\0';
   muscle_pair_list_grow (type, decl, name);
   free (name);
 }

Actually, I don't understand why we don't use strspn instead of
the for-loop.

[PATCH 2/3] maint: simplify parse-gram.y

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

From: Jim Meyering <meyering< at >redhat.com>

* src/parse-gram.y (add_param): Use xstrdup in place of xmalloc+memcpy.
---
 src/parse-gram.c | 723 ++++++++++++++++++++++++++++---------------------------
 src/parse-gram.y |   4 +-
 2 files changed, 366 insertions(+), 361 deletions(-)

diff --git a/src/parse-gram.c b/src/parse-gram.c
index 7125d12..7c87fce 100644
--- a/src/parse-gram.c
+++ b/src/parse-gram.c
< at >< at > -1,4 +1,4 < at >< at >
-/* A Bison parser, made by GNU Bison 2.4.687-d4fc-dirty.  */
+/* A Bison parser, made by GNU Bison 2.5.831-f2f0-dirty.  */

 /* Bison implementation for Yacc-like parsers in C

< at >< at > -44,7 +44,7 < at >< at >
 #define YYBISON 1

 /* Bison version.  */
-#define YYBISON_VERSION "2.4.687-d4fc-dirty"
+#define YYBISON_VERSION "2.5.831-f2f0-dirty"

 /* Skeleton name.  */
 #define YYSKELETON_NAME "yacc.c"
< at >< at > -129,6 +129,14 < at >< at > static char const *char_name (char);
 /* Line 269 of yacc.c  */
 #line 131 "src/parse-gram.c"

+# ifndef YY_NULL
+#  if defined __cplusplus && 201103L <= __cplusplus
+#   define YY_NULL nullpt

[PATCH 3/3] maint: regen src/parse-gram.[ch]

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

From: Jim Meyering <meyering< at >redhat.com>

---
 src/parse-gram.c |  8 +++-----
 src/parse-gram.h | 12 ++++++------
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/src/parse-gram.c b/src/parse-gram.c
index 7c87fce..e1c32cc 100644
--- a/src/parse-gram.c
+++ b/src/parse-gram.c
< at >< at > -1,4 +1,4 < at >< at >
-/* A Bison parser, made by GNU Bison 2.5.831-f2f0-dirty.  */
+/* A Bison parser, made by GNU Bison 2.5.832-4247-dirty.  */

 /* Bison implementation for Yacc-like parsers in C

< at >< at > -44,7 +44,7 < at >< at >
 #define YYBISON 1

 /* Bison version.  */
-#define YYBISON_VERSION "2.5.831-f2f0-dirty"
+#define YYBISON_VERSION "2.5.832-4247-dirty"

 /* Skeleton name.  */
 #define YYSKELETON_NAME "yacc.c"
< at >< at > -3411,9 +3411,7 < at >< at > add_param (param_type type, char *decl, location loc)
            name_len++)
         continue;

-      name = xmalloc (name_len + 1);
-      memcpy (name, name_start, name_len);
-      name[name_len] = '\0';
+      name = xstrdup (name_start);
       if (type & param_lex)
         muscle_pair_list_grow