Re: too many warnings from Bison CVS for Pike

[Hans Aberg]

On 21 Feb 2006, at 06:12, Paul Eggert wrote:

> > You are definitely wrong about that: Paul wrote the dynamic
> > extensions, I recall.
>
> No, Akim's right: the Yacc skeleton has supported dynamic reallocation
> of the stack since 1993.  RMS is well-known for disliking arbitrary
> limits, and one of the changes he installed in 1993, as compared to
> the earlier skeleton by Corbett with a fixed-size stack, was support
> for dynamic reallocation.  Like the current yacc.c, RMS's
> implementation method used the equivalent of memcpy, so it was not
> compatible with fancy C++ types.
>
> This can all be easily verified by consulting the Bison CVS history.

What I remember is from some old Bison version 1.35, 1.27 or something.

But the exact history is not as important as such here.

One can disable the dynamic stack, and use it with non-POD's, which I  
suspect some do.

> > These are the parts you need to clear up,
>
> It would be helpful to have better documentation.  I suggested on
> February 14 in this thread that it would help if you would propose
> specific patches, in "diff -u" format, and you wrote back that you'd
> think about it.  Let's do that, instead of wasting further time
> arguing about ancient history.

If you are addressing me, the problem is that you ask me to write  
what is in Akim's head only!

> Please bear in mind that we want documentation that is short, simple,
> and sweet.  Long explanations that talk about C++ versus C, the
> ancient history of Bison, proper object-oriented style, name space
> philosophy, etc., etc., are not likely to be accepted.  Personally, I
> suspect this matter could be explained well in five lines or less.
> (I'm not a C++ expert so I'm not the right person to write it.)

As soon one knows what is supported, and how.

It would be best if Akim somewhere jotted down what support he is  
giving.

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

> As far as I'm concerned it's clear: as long as the user sticks to PODs
> and does not expect C++ magic, then it should work.  But as soon as
> the user becomes too much of a problem, user support might be  
> dropped ;)

This suggests:

  Compiling the C-parser using a C++ compiler

An effort is made to make the C-parser compilable using a C++  
standard conforming compiler, as long as the semantic and location  
types (if used) are POD's. This support may be dropped in future  
Bison versions.

  Hans Aberg