GNU bug report logs - #50469
[bison-3.8] bug or side effect to flex & automake

Previous Next

Package: automake;

Reported by: Akim Demaille <akim <at> lrde.epita.fr>

Date: Wed, 8 Sep 2021 05:33:01 UTC

Severity: normal

Done: Karl Berry <karl <at> freefriends.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Akim Demaille <akim <at> lrde.epita.fr>
To: Kiyoshi KANAZAWA <yoi_no_myoujou <at> yahoo.co.jp>
Cc: eggert <at> CS.UCLA.EDU, 50469 <at> debbugs.gnu.org, bug-bison <at> gnu.org
Subject: bug#50469: [bison-3.8] bug or side effect to flex & automake
Date: Wed, 8 Sep 2021 07:31:28 +0200
Hi Kiyoshi,

> Le 8 sept. 2021 à 04:11, Kiyoshi KANAZAWA <yoi_no_myoujou <at> yahoo.co.jp> a écrit :
> 
> Hello,
> 
> Installed bison-3.8, but I'm afraid it is has bug or side effect to flex-2.6.4 & automake-1.16.4.
> 
> $ uname -a
> SunOS hidden 5.11 11.3 i86pc i386 i86pc
> 
> $ gcc --version
> gcc (GCC) 10.3.0
> 
> After installing bison-3.8, detected the following make check error, which did not with bison-3.7.6.
> 
> (1) flex-2.6.4
> mv -f $depbase.Tpo $depbase.Po
> depbase=`echo bison_nr_parser.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> gcc -m32 -DHAVE_CONFIG_H -I. -I../src  -I../src -I../src    -MT bison_nr_parser.o -MD -MP -MF $depbase.Tpo -c -o bison_nr_parser.o bison_nr_parser.c &&\
> mv -f $depbase.Tpo $depbase.Po
> bison_nr_parser.c:70:25: error: conflicting types for 'testerror'
>    70 | #define yyerror         testerror
>       |                         ^~~~~~~~~
> bison_nr_parser.y:40:5: note: in expansion of macro 'yyerror'
>    40 | int yyerror(const char* msg);
>       |     ^~~~~~~
> In file included from bison_nr_parser.y:33:
> bison_nr_parser.h:110:6: note: previous declaration of 'testerror' was here
>   110 | void testerror (const YYLTYPE *yyllocp, const char *msg);
>       |      ^~~~~~~~~
> bison_nr_parser.c:70:25: error: conflicting types for 'testerror'
>    70 | #define yyerror         testerror
>       |                         ^~~~~~~~~
> bison_nr_parser.y:93:5: note: in expansion of macro 'yyerror'
>    93 | int yyerror(const char* msg) {
>       |     ^~~~~~~
> In file included from bison_nr_parser.y:33:
> bison_nr_parser.h:110:6: note: previous declaration of 'testerror' was here
>   110 | void testerror (const YYLTYPE *yyllocp, const char *msg);
>       |      ^~~~~~~~~
> make[2]: *** [Makefile:2076: bison_nr_parser.o] Error 1
> 
> And so on.

Well, I'm afraid this change was made on purpose, to conform with the (unfortunate IMHO) latest specs of POSIX Yacc.  See the NEWS file:

  To comply with the latest POSIX standard, in Yacc compatibility mode
  (options `-y`/`--yacc`) Bison now generates prototypes for yyerror and
  yylex.  In some situations, this is breaking compatibility: if the user
  has already declared these functions but with some differences (e.g., to
  declare them as static, or to use specific attributes), the generated
  parser will fail to compile.  To disable these prototypes, #define yyerror
  (to `yyerror`), and likewise for yylex.

This change in POSIX was discussed here: https://austingroupbugs.net/view.php?id=1388#c5220.  However, I don't see a published version of the POSIX Yacc "specs" that includes these changes.  The latest edition appears to be from 2018 (https://pubs.opengroup.org/onlinepubs/9699919799/).


That being said, several tests can be easily adjusted.  For instance t/silent-yacc fails because it provides this implementation of yyerror:

void yyerror (char *s) { return; }

while the expected signature is

void yyerror (const char *s);

I have not checked all the tests, but I suspect that many of them can be easily fixed.

I don't see you, Kiyoshi, in the logs of Automake, so I suppose you are not maintaining/contributing to Automake.  Yet we need to fix these tests (I'd be happy to get feedback from Automake's team on this).


This is definitely a change that may break compatibility in some cases, but it's out of our control: POSIX decided, we just comply.  One big problem with the Autotools as of today is that they promote the use of macros/build rules for Yacc, not for Bison.  Because of this, bison is almost always called with `-y/--yacc`, which not only forces bison to generate y.tab.c instead of foo.tab.c, but also forces it to enter the POSIX Yacc mode (and also to spit tons of warnings for each GNU Bison feature which is not part of POSIX Yacc).


Cheers!



This bug report was last modified 3 years and 245 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.