Re: yacc.c does not prototype yyparse in the header

[Akim Demaille]

Le 11 juin 2012 à 11:29, Paul Eggert a écrit :

> On 06/11/2012 01:54 AM, Akim Demaille wrote:
>> Bruce Korb just pointed out to me that Bison 2.5.1 does
>> not prototype yyparse in the generated header, with yacc.c.
>> The other skeletons do.  I don't understand why.
> 
> This is for historical reasons, as Bison
> historically generated parsers that compiled with
> traditional C compilers that did not support prototypes.
> Nowadays that is no longer a concern, and yyparse can
> use prototypes unconditionally.
> 
>> I guess we only have
>> to pay attention to handle %prefix via M4, and not via CPP
> 
> I would think so, yes.

hi Paul,

There are two issues that annoy me on this regard.

First, there are no CPP guards used in our generated headers
(for yacc.c).  I would very much like them to have some, especially
because in some cases it might help us simplify some of the "inner"
guards we have (to avoid multiple definitions of the same
typedefs for instance).

Second, I never really paid attention to this before,
but how on earth can it be really useful to rename the
global variables (--name-prefix) such as yylval, global
functions, such as yyparse, but not the global types, such as
YYSTYPE???  Today, with --name-prefix=foo, one reads in the
generated header:

> #if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
> typedef union YYSTYPE
> {
>   int ival;
> } YYSTYPE;
> # define YYSTYPE_IS_TRIVIAL 1
> # define yystype YYSTYPE /* obsolescent; will be withdrawn */
> # define YYSTYPE_IS_DECLARED 1
> #endif
> 
> extern YYSTYPE foolval;

Am I missing something, or is this the sign that surely, no
one really uses several parsers within a single application?
Well, at least, not from a single compilation unit, but
really, how about addressing this shortcoming?