Re: Bison and g++: It's been broken for more than a year!

[Hans Aberg]

At 18:37 -0400 2004/07/09, Jim Babcock wrote:
>The most recent official version of bison is 1.875. That is the version
>bundled with every distro I have around to try. It has been that way for
>more than a year. Given that, you would expect it to be free of major
>bugs. But 1.875 is completely unusable with C++, because its output
>includes the following:
>   yyerrlab1:
>   #if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
>     __attribute__ ((__unused__))
>   #endif
>After running into this with my own project, and finding a really
>disgusting workaround ("#undef __GNUC__" in the header section), I
>ran into the problem *again* with the ctree source package. I traced
>the problem through gcc's bugzilla where I found that the g++ devs
>explicitly reject this construct, and that g++ never supported it in
>the first place.

None of the official Bison releases ever officially supported the compile C
as C++ possibility, even though the skeleton fields were written in order
to support that unofficially. One thing that a dynamic C-stack won't
support is to properly invoke the C++ copy-constructors when the stack is
re-allocated. If you use the %union option & an ISO-C++ compliant compiler,
then you are safe, though because only POD's, with trivial such
constructors can be used in a C/C++ union.

So when you start to compile C as C++, then you are already on shaky grounds.

> So I proceed to here, where searching the list
>archives, I discover that the issue has been fixed in an alpha version
>since Jan 2003.
>
>   WHY is there still no Bison 1.876?
>
>When a release-critical bug is found, the fix should be backported
>and a new version released as soon as possible. Instead, the bug has
>sat there for more than a year. Who, exactly, is in charge of release
>management?

The best way is to address development issues on the Bug-Bison list
<address@hidden>.

For some reason, the none of the later development releases where upgraded
to an official distribution. But I think that you should probably use on of
them.

Alternatively, you can modify the skeleton C-skeleton file and distribute
that one instead.

>There's simply no way I can give my program a dependency on an
>unofficial version of bison. So I'm either going to find another
>parser generator, or just use C.

There was a C++ skeleton file written that comes with the Bison
distribution. As I could not get it working, I modified it to a working
one. The details are in the Bison-Patches list. You may use it if your
semantic type uses non-POD's, but it is not thread safe.

  Hans Aberg