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!)
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison