Re: bison 2.6.2 generates incompatible header file

[Bill Allombert]

On Thu, Oct 18, 2012 at 09:18:08AM +0200, Akim Demaille wrote:
> 
> Le 17 oct. 2012 à 20:00, Chuan-kai Lin a écrit :
> 
> > Hi,
> 
> Hi all,
> 
> 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"?

Yes, please see the test-case I sent yesterday.

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

It is frequent that people use C++ compiler to compile C code.
It is also frequent to write some part in C and some part in C++
and to share header files.

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

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

A way to fix the problem could be to add

#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif

in the generated parse.tab.h.

Cheers,
-- 
Bill. <address@hidden>

Imagine a large red swirl here.