Re: too many warnings from Bison CVS for Pike

[Hans Aberg]

On 20 Feb 2006, at 15:39, Akim Demaille wrote:

> > > > "Hans" == Hans Aberg <address@hidden> writes:
>
> > 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 don't remember why it's like this,

Because it has always been so, and you, according to you earlier  
comment about "an effort is made sure it compiles under C++", which I  
gather can only refer to your own checks, is giving support to it.  
Paul Eggert later extended this original static C-parserstack to  
becoming dynamic. Apparently is is used alos as C++ code  
automatically when invoking %union.

> but it's already something that
> seems to be too much in favor of C++: I would have used memcpy.)
>
> > 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.
>
> You're referring to yacc.c, and all your comments about how to do C++
> using yacc.c is irrelevant and a pure waste of time.

You are one wasting time, then by making sure it compiles under C++.

> If you want to
> play C++, use lalr1.cc, period. If you don't like it, use another.

I can't use it, nor another one, because I did not get the code  
placement version of %define. Neither can I nor you use the Bison  
static type system with C++ non-POD's. What is happening there?

> But let's stop this useless debate and go back to work.

I am in favor of dropping the compile C as C++ option altogether, and  
I figure so is Paul Eggert. You are then the one wasting other  
peoples time by insisting on having this option supported.

  Hans Aberg