bug-bison
[Top][All Lists]
Advanced

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

Re: bison 2.6.2 generates incompatible header file


From: Akim Demaille
Subject: Re: bison 2.6.2 generates incompatible header file
Date: Thu, 18 Oct 2012 09:18:08 +0200

Le 17 oct. 2012 à 20:00, Chuan-kai Lin a écrit :

> Hi,

Hi all,

Thanks for the detailed bug report.

> I am forwarding this bug report by Bill Allombert from the Debian bug
> tracking system (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689700).
> Here is Bill's report:
> 
> """
> This version (2.6.2) of bison -d parse.y generates a parse.h ending
> file with the following
> (assuming the file contain
> %parse-param {char **lex}
> )
> 
> #ifdef YYPARSE_PARAM
> #if defined __STDC__ || defined __cplusplus
> int parse (void *YYPARSE_PARAM);
> #else
> int parse ();
> #endif
> #else /* ! YYPARSE_PARAM */
> #if defined __STDC__ || defined __cplusplus
> int parse (char **lex);
> #else
> int parse ();
> #endif
> 
> This was not done in bison 2.4.1 and earlier release, and as far as I
> can see this
> change is not documented anywhere.

Actually it is.  In NEWS:

* Noteworthy changes in release 2.6 (2012-07-19) [stable]

[…]

** Generated Parser Headers

[…]

*** New declarations (yacc.c, glr.c)

  The generated header now declares yydebug and yyparse.  Both honor
  --name-prefix=bar_, and yield

    int bar_parse (void);

  rather than

    #define yyparse bar_parse
    int yyparse (void);

  in order to facilitate the inclusion of several parser headers inside a
  single compilation unit.

> This is unfortunate because this does not necessarily declare int
> parse (char **lex)
> in the right C++ namespace, causing conflict with the user supplied prototype
> (which is certainly necessary with older releases), causing compilation error.
> """
> 
> Was this change a regression?  Or was it intentional?  Please let us
> know whether
> you could provide a patch to fix the problem, or instructions on how
> software that
> depend on bison should accommodate this new behavior.

The change is intentional, the absence of prototype was complained
about several times.

I'd be happy to have more details about the original use case to understand
what the best solution is.

I don't understand what you, Bill, mean by "the right C++ namespace", as
yyparse is certainly not put in any namespace at all in the *.c file,
so it would make no sense for it to be in one in the header.  So
I expect you mean extern "C"?

If the parse is meant to be used from C, why is it compiled in C++?

If the parser is meant to be used in C++, why the extern "C"?

But if the parser is using C++ stuff in its implementation,
(then, how about using the C++ output of Bison?) and
must export some "C" interface, then the simplest, safest, and
most portable solution is certainly to wrap the call to yyparse
from a function declared extern "C", fully under the control
of the user.

So really, I'd like to see actual breakage to understand what's
the best course of action from now.




reply via email to

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