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

[Hans Aberg]

On 20 Oct 2007, at 21:31, David Fang wrote:

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

> 	(This is not the issue of the original problem, but I'll address  
> this while I'm at it.)  If fact, I do use POD pointers in the  
> semantic type in a %union.  I'm not depending on bison's C skeleton  
> for C++ features and semantics, those are merely in the way I use  
> the semantic types in my actions (e.g. member functions, calls to C+ 
> + library).  And the source transformation I do emits type-safe  
> clean-up functions equivalent to %yydestruct before it came along  
> -- I still support older versions of bison and traditional yacc,  
> since many distros/vendors have not caught up.  Anyways, back to  
> the original issue...

So then it might work, though you are on your own.

> > > 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.
>
> It's clear where you stand on that matter, however, I ask you  
> +developers to consider the attached patch (for yacc.c) in bison 2.3 
> + (looks similar to 2.1).  This should not perturb C usage of the C  
> skeleton, only improve support for use with C++ in the rare case  
> I've encountered.  It would be a shame to drop C++ compiling of the  
> C skeleton, since it has worked so well for such a long time -- it  
> has completely C++-warning-clean even with the strictest options.   
> (Or please give a reason why this patch won't work or is too  
> risky.)  I am willing to help maintain unofficial support.  :

You can send it to the Bison-Patches list. But it was decided once  
for all, several years ago, to not support compile C as C++.

> > 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.
>
> Sure, the two parsers should be separate since they are different,  
> I'm not asking for a feature of one to be ported to the other.  
> However, for compatibility reasons, I cannot ask my users to use  
> the experimental C++ parser, just not yet.

It is not experimental. Compile C as C++ always was.

  Hans Aberg