Re: bison 2.6.2 generates incompatible header file

[Akim Demaille]

Hi Bill,

Le 22 oct. 2012 à 23:15, Bill Allombert a écrit :

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

I see no reason for this.  C++ is (virtually) upwardly compatible with
C, there is no reason to let the C parser be compiled with a C++
compiler is a special way.

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

Well, reversed question then :)

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

I had seen the Makefile, I had studied it (sorry I wrote about
in the reversed way), but the question remains: why do you
compile the parser with a C compiler?

I'm asking for real world example, projects that are broken
by these changes and that were not "wrong" in some way. As
far as I can see, for the real world Debian projects mentioned
so far, the issues were classified as "not due to the Bison
release, but revealed by it".

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

But we do agree that the point of 'extern "C"' is to export/import
interfaces.

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

Sorry, but we don't agree about this being "a bug".  It does not suit
your expectations, agreed, yet, so far, I don't consider it a bug.  And
it does not need to be a bug for Bison to be adjusted to this, I just
need some real world example that proves that there are valid
use cases that are not properly covered, and that I can study to see
what the best option is.

> Without knowing about this problem, adding
> int myparse(void)
> {
>  return yyparse();
> }
> seems completly useless.

Not to someone who plays to mix C and C++ in a single project.

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

Let me emphasize this: there is no need to compile a parser in C 
generated by Bison with a C compiler.