Re: too many warnings from Bison CVS for Pike

[Hans Aberg]

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