Re: bison 2.6.2 generates incompatible header file

[Bill Allombert]

On Thu, Oct 18, 2012 at 02:15:38PM +0200, Akim Demaille wrote:
> Hi Bill,
> 
> > (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.

The problem is that testing is frozen so this is not an option.
The real fix is to refrain from uploading new major version of bison to 
unstable 
during a freeze.

By the way, the real package breaking is csound. The log is here:
<https://buildd.debian.org/status/fetch.php?pkg=csound&arch=i386&ver=1%3A5.17.11~dfsg-2&stamp=1348960646>
(I am not involved with csound in anyway, though)

> > 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".

I agree, but I guess it is your turn to give an example that work with bison
2.5 and 2.6 but would not work with my change.

As far as I see, this requires the user to build parse.tab.c with g++, otherwise
parse() will have C linkage anyway. C++ requires prototypes, so the user needs 
to
provide a prototype for parse() when using bison 2.5 at least.
When you allow to compile C files with a C++ compiler, it is customary to use 
extern "C", otherwise you ABI depend on the compiler.

But I quite understand why you would be wary of apply this change.
Maybe documenting to do 
extern "C" {
#include "parse.tab.h"
}
in case of problem is the lesser evil.

Cheers,
-- 
Bill. <address@hidden>

Imagine a large red swirl here.