[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Akim Demaille
Subject: Re: yacc.c does not prototype yyparse in the header
Date: Tue, 12 Jun 2012 15:54:11 +0200

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;
> # define yystype YYSTYPE /* obsolescent; will be withdrawn */
> #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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]