Re: bison 2.6.2 generates incompatible header file

[Akim Demaille]

Hi Bill,

Le 18 oct. 2012 à 10:30, Bill Allombert a écrit :

> On Thu, Oct 18, 2012 at 09:18:08AM +0200, Akim Demaille wrote:
>> 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"?
> 
> Yes, please see the test-case I sent yesterday.

I just wanted to clarify your use of "namespace", I did check
the example.


>> 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.
> 
> Or you can just do
> extern "C" {
> #include "parse.tab.h"
> }
> 
> but the point is that it is breaking backward compatibility, and no advance
> notice was provided. The NEWS field does not mention this requirement.

I can make the NEWS entry clearer if you want, still I would
like to see genuine code facing the problem your example
describes.

> (and more to the point, Debian 'testing' includes bison 2.5 and
> Debian 'unstable' includes bison 2.6 and some software in 
> 'testing' does not build on 'unstable', but this is something for
> the Debian maintainer to deal with.)

I'd be happy to help, as in the past, we also "broke" the backward
compatibility by fixing bugs in Bison that revealed incorrect code
in user code; this ended by fixing the code that was relying on a
bug in Bison.

> A way to fix the problem could be to add
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> ...
> #ifdef __cplusplus
> }
> #endif
> 
> in the generated parse.tab.h.

This is not correct for people who do not want this guy to be
in extern "C".