[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);
#endif
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.
Frank
- bison 2.6.2 generates incompatible header file, Chuan-kai Lin, 2012/10/17
- Re: bison 2.6.2 generates incompatible header file, Bill Allombert, 2012/10/17
- Re: bison 2.6.2 generates incompatible header file, Akim Demaille, 2012/10/18
- Re: bison 2.6.2 generates incompatible header file, Bill Allombert, 2012/10/18
- Re: bison 2.6.2 generates incompatible header file, Akim Demaille, 2012/10/18
- Re: bison 2.6.2 generates incompatible header file, Bill Allombert, 2012/10/18
- Re: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file,
Frank Heckenbach <=
- Re: *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file, Frank Heckenbach, 2012/10/18
- Re: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file, Bill Allombert, 2012/10/18
- Re: bison 2.6.2 generates incompatible header file, Frank Heckenbach, 2012/10/18
- Re: bison 2.6.2 generates incompatible header file, Akim Demaille, 2012/10/19
- Re: *** GMX Spamverdacht *** Re: bison 2.6.2 generates incompatible header file, Frank Heckenbach, 2012/10/19
- Re: bison 2.6.2 generates incompatible header file, Akim Demaille, 2012/10/19
- Re: bison 2.6.2 generates incompatible header file, Akim Demaille, 2012/10/21
- Re: bison 2.6.2 generates incompatible header file, Chuan-kai Lin, 2012/10/21
- Re: Bug#689700: bison 2.6.2 generates incompatible header file, Chuan-kai Lin, 2012/10/29
Re: bison 2.6.2 generates incompatible header file, Bill Allombert, 2012/10/22