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

[David Fang]

> > > > 	I've just encountered a problem where the compiler rejects bison's 
> > > > prototype for "void* malloc(YYSIZE_T);" because it doesn't match with 
> > > > <stdlib.h>, which looks like "void* malloc(size_t) __THROW ... ;" 
> > > > (ubuntu7).  The problem only manifests when compiling the resulting 
> > > > source file as in C++ (otherwise, the __THROW macro is empty).  It looks 
> > > > like the bison skeleton is using "defined __cplusplus" to conditionally 
> > > > insert this prototype, rather than including <cstdlib>, a standard C++ 
> > > > wrapper header, which should resolve the inconsistency, and be safely 
> > > > portable.
> > >
> > > Well, is it the C or C++ header? In C++, standard names start with 
> > > "std::".
>
> > The error message was pointing to "the original declaration" in 
> > /usr/include/stdlib.h, which already contained provisions for C++ 
> > (namespace, no-throw specification) without going through <cstdlib>.  In 
> > any case, the prototype mismatch is attributed to the difference in the 
> > throw specification, which is missing from the bison skeleton's version 
> > (not any other issue).  The quick fix I see is to just include <stdlib.h> 
> > or if __cplusplus, <cstdlib>.  If this results in std::malloc, then a 
> > conditional definition of a "std::" namespace prefix should take care of 
> > calls to malloc in C++ mode.  Thoughts?
> >
> > Actually, I misspoke about the platform: it was occuring on ubuntu6 not 7.
>
> 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.)

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

Fang

David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
        -- (2400 baud? Netscape 3.0?? lynx??? No problem!)