[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible head

From: Frank Heckenbach
Subject: Re: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file
Date: Thu, 18 Oct 2012 18:52:41 +0200

Bill Allombert wrote:

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

FWIW (not sure if it's a relevant example, since I haven't tried
with the newer Bison versions yet; we use the one in squeeze):

We do compile our Bison output with g++ (yes, we should probably use
the C++ skeleton, but we haven't gotten around to it yet), and we
don't use extern "C" -- in fact we use two different parsers in one
executable and we put them in different C++ namespaces to avoid
conflicts. (After the recent changes, this may no more be necessary
as I understand, we'll have to check this after an upgrade ...)

Currently we have in our *.y:

#define IN_BISON

and in our common header:

#ifndef IN_BISON
int yyparse (params);

IIRC, with earlier Bisons, it worked without the #ifndef, now it
produces a duplicate declaration, so I suppose that's the relevant
change in Bison and our workaround.

So I guess what this means is (a) blindly applying extern "C" would
be wrong and (b) the situation is currently not nice, but acceptable
(to us) with the above workaround, but at least that's temporary --
after dropping support for older Bisons, we won't have to declare
yyparse at all which is (slightly) better than always having to
declare it as it was before.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]