Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode)

[Hans Aberg]

On 20 Oct 2007, at 10:09, David Fang wrote:

> > I meant: do you Bison-compile to generate C or C++ output.
>
> I generate the C LALR(1) output, but compile it in C++ (using STL  
> containers and algorithms).  (I also perform some major  
> postprocessing and automatic source-rewriting on the resulting .cc  
> file, but that doesn't change the current problem.)

That is not supported. It might work if you use a POD in the semantic  
type (a must if %union is used), but the C output does support C++  
copy constructors when the parser stack is reallocated.

> > Once upon the time, the C output had informal support for C++, but  
> > that was dropped, I think. The "if __cplusplus" suggests you have  
> > some compile for C that does not work with C++.
>
> I'm not sure what ever happened officially.  But I have been using  
> the C lalr1 skeleton in C++ compiles for years (from v. 1.35 to  
> 2.3, also good-old Berkeley yacc) on FreeBSD, SuSE-linux, Mac OS X,  
> without ever having run into this problem (or other problems for  
> that matter), until someone else reported this build-fail on  
> ubuntu6.  I've been counting on that LALR C skeleton to be rather  
> stable, which is why I compile it instead of the C++ parser.
>
> My impression was that the C output is still supported with C++  
> compilation given the success I've had with it, and seeing evidence  
> of accommodating C++ in the resulting output.  (It would be a good  
> thing to maintain!)  Since this (above) seems like an easy and safe  
> fix, I hope that it might be adopted.  I can generate the proposed  
> patch after I get some test feedback from the reporter.

Compile C as C++ was never officially supported, but some time  
inofficially.

But because of problems with that, it was decided to keep C and C++  
skeletons and thus parser output separate.

So for C++, use a C++ parser output.

  Hans Aberg