[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: Tue, 21 Feb 2006 07:54:29 +0100

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

reply via email to

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