Re: bison 2.6.2 generates incompatible header file

[Bill Allombert]

On Thu, Oct 18, 2012 at 09:18:08AM +0200, Akim Demaille wrote:

Sorry for the late answer. I am not a C++ expert, so I need some time
to digest the issue.

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

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

It is not: in my example parse.tab.c is compiled with gcc.

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

Because parse.tab.c is written in C , but proj.c is in C++.
See the makefile:
        gcc -c parse.tab.c -o parse.tab.o
        g++ proj.c parse.tab.o -o proj

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

It does not need to "export", it needs to "import" a "C" interface
from parse.tab.c.

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

I do not see how the user can guess this is something desirable to do
before learning about this bug.

Without knowing about this problem, adding
int myparse(void)
{
  return yyparse();
}
seems completly useless.
Users are much more likely to wrap the call to yyparse inside a C++ function,
but then then have to add a prototype for yyparse in extern "C" and then the
bug kick in.

Cheers,
-- 
Bill. <address@hidden>

Imagine a large red swirl here.