bug#50469: [bison-3.8] bug or side effect to flex & automake

[Akim Demaille]

Hi Kiyoshi,

> Le 8 sept. 2021 à 04:11, Kiyoshi KANAZAWA <yoi_no_myoujou@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!