[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode)
From: |
David Fang |
Subject: |
Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode) |
Date: |
Sat, 20 Oct 2007 15:31:40 -0400 (EDT) |
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.
Hi,
(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...
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. :D
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.
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!)
bison.patch
Description: Text document
- malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode), David Fang, 2007/10/19
- Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode), Hans Aberg, 2007/10/19
- Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode), David Fang, 2007/10/19
- Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode), Hans Aberg, 2007/10/20
- Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode), David Fang, 2007/10/20
- Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode), Hans Aberg, 2007/10/20
- Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode),
David Fang <=
- Re: malloc: bison-2.1+, prototype mismatch vs. stdlib.h (C++ mode), Hans Aberg, 2007/10/20