Re: bison 2.6.2 generates incompatible header file

[Akim Demaille]

Hi all!

Le 18 oct. 2012 à 17:53, Bill Allombert a écrit :

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

Well, now that Bison 2.6 is in, maybe the simplest is still
to fix incorrect uses?  I might be mistaken, but I am under
the impression that we seem to converge on the idea that
Bison is rightful in its change (yet it does break some builds),
and there is no need to introduce workarounds in it.

Nevertheless (I don't know Debian's schedule), there are a
few bugs in 2.6.2 that have been fixed, and are scheduled
to be released in 2.7 (say a couple of weeks).  Would Debian
folks like a 2.6.3 with just the bug fixes part of 2.7?  I
can prepare this quickly if you wish.

> 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)

Thanks for the pointer!


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

:)

You are preventing people to overload yyparse for instance.
Your suggestion is clearly a workaround to address the
situation at hand, but we both agree (that's my reading
for the end of your message) that that's not the way to
go in the long run, so I'd rather not introduce it and
face new bugs because of this.

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

I can suggest this, but I would have to draw the attention
of C++ programmers who use the C generated parser to pay
attention that then everything they define in their
parser must not rely on C++ mangling :/

I could leave such a note in a NEWS entry for 2.6.3, would
that suffice in your opinion?