Re: implicit declaration of function 'yylex' is invalid in C99

[Akim Demaille]

Hi Ryan,

> Le 14 janv. 2022 à 10:52, Ryan Schmidt <bison@ryandesign.com> a écrit :
> 
> Hi,
> 
> On macOS 10.15 or later with bison 3.8.2, flex 2.6.4, and Xcode 12 or later, 
> when software is built that uses bison/flex, I often see this type of failure:
> 
> 
> error: implicit declaration of function 'yylex' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>      yychar = YYLEX;
>               ^
> note: expanded from macro 'YYLEX'
> # define YYLEX yylex ()
>               ^
> 
> 
> As of Xcode 12, implicit declaration of function is an error. You must 
> provide a function prototype before you call a function.
> 
> A quick search shows many people encountering this problem:
> 
> https://stackoverflow.com/questions/69986502/i-get-some-error-when-i-try-to-complie-yacc-lex-file
> https://stackoverflow.com/questions/23717039/generating-a-compiler-from-lex-and-yacc-grammar
> https://trac.macports.org/ticket/62015
> https://trac.macports.org/ticket/62632
> 
> It sounds very much like the problem reported to this mailing list in 2005:
> 
> https://lists.gnu.org/archive/html/bug-bison/2005-05/msg00055.html
> 
> A fix was proposed there as well. Does anyone know if that proposal was ever 
> accepted? It's difficult for me to determine because I'm not familiar with 
> the bison source code and it has probably evolved significantly since 2005.

I've explained why this is a bad idea (IMHO) in 
https://austingroupbugs.net/view.php?id=1388#c5206.

There are several reasons.  Let's focus on yylex.

First of all, why the heck would the *consumer* (Bison generated parser) have 
the specify that instead of the *provider* (for instance Flex generated 
scanner, or whatever the other tools)?  It feels not right.

Second of all, there are several possible prototypes, depending the user's 
requirements.  What return type are you using to code tokens (int, enum)?  Is 
yylex static?  Are its arguments const?  etc.  As a matter of fact, to get 
compliant with a recent change in POSIX Yacc, we (reluctantly) started 
generating these prototypes, which immediately broke existing code that had 
slightly different prototypes 
(https://lists.gnu.org/r/bug-bison/2021-09/msg00005.html).  See the NEWS entry 
on this regard:

* Noteworthy changes in release 3.8 (2021-09-07) [stable]

** Backward incompatible changes

  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.

* Noteworthy changes in release 3.8.1 (2021-09-11) [stable]

  The generation of prototypes for yylex and yyerror in Yacc mode is
  breaking existing grammar files.  To avoid breaking too many grammars, the
  prototypes are now generated when `-y/--yacc` is used *and* the
  `POSIXLY_CORRECT` environment variable is defined.

  Avoid using `-y`/`--yacc` simply to comply with Yacc's file name
  conventions, rather, use `-o y.tab.c`.  Autoconf's AC_PROG_YACC macro uses
  `-y`.  Avoid it if possible, for instance by using gnulib's gl_PROG_BISON.

I personally feel that generating these prototypes automatically is actually 
more complex (for the user, not for Bison) than merely specifying them.

Cheers!