|
From: | Hans Aberg |
Subject: | Re: too many warnings from Bison CVS for Pike |
Date: | Mon, 13 Feb 2006 23:03:34 +0100 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |