On 13 Feb 2006, at 20:41, Paul Eggert wrote:
I said that I recall you use(d), under C, memcpy to reallocate the
parser stack.
No, not if the compiler defines __cplusplus. If the compiler defines
__cplusplus, yacc.c does not use memcpy at all.
I saw that, and that is also inherent in the comments I made: When
compiled using a C++ compiler, only the static C-parserstack is used,
which does not use memcpy. This leads to a non-standard C++ container
semantics, as the whole array is initialized when first created at
parser invocation, and when the stack shrinks, only a pointer to the
array is changed, so the C++ destructors will not be invoked. A
proper C++ container would do these things immediately at need only
as the stack grows and shrinks.
One might use the dynamic C-parserstack which uses memcpy as well,
which will then work only for POD types, and you already have put in
a union that causes a proper C++ compiler to generate an error if
somebody tries to use a non-POD type.
If one uses %union then the type must be a POD type, so one can then
just as well use the dynamic C-parser stack. However, I do not know
if people do that, so I cannot tell whether it is worth to support this.
Could you please suggest a specific patch, in "diff -u" format?
I'll see if I can come up with some suggestion for say a Bison
section "Compiling C parsers using a C++ compiler". But Akim, who I
gather is the maintainer of this feature, would have to OK it; I can
only guess what it might be.
The
point is that all we try to do is to support C compilers. This
includes C++ compilers masquerading as C compilers. It does not
include support for C++ features like C++ destructors.
When compiled using a C++ compiler, that becomes C++ code, so
destructors and such will be implemented by the compiler. The problem
is to get them to become invoked at the proper, expected times.
Before C++ had a standard library, one had to implement suitable
containers by oneself, or at least I did. So it is not impossible to
do so that the C-parser will behave properly also under C++: just
keep track of the places where the stack is altered, and put in the
appropriate code there that otherwise would be part of a C++
container implementation. But it is not worth the effort. The focus
of the C-parser, I think, should be to get it working under C.
Perhaps this C++ compile option should be phased out at some point,
when the C++ skeletons have become finished.
Hans Aberg
