[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: too many warnings from Bison CVS for Pike

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]