[Top][All Lists]

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

Re: Reductions during Bison error handling

From: Akim Demaille
Subject: Re: Reductions during Bison error handling
Date: 24 May 2002 08:43:16 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

>>>>> "Richard" == Richard Stallman <address@hidden> writes:

> A program relying on an unsupported Bison feature, perhaps
> undocumented, discovered by trial and error or reading the sources
> or whatever, and breaks when Bison is updated must expect to be
> rewritten.

Richard> For some programs, that policy is acceptable.  The nature of
Richard> the job Bison does requires a more cautious policy, as I
Richard> explained before.  I expect the Bison maintainers to give
Richard> compatibility a very high priority.

We all agree about this, but the situations where the behavior can be
observed are very specific, and very unlikely to be exhibited.
Actually, it is so unlikely that if the bug is discovered today, it's
only because someone, Paul Hilfinger, took some time to fully analyze
the skeleton, *not* because someone actually triggered the bug.

The current behavior is so obscure that one cannot depend on it: it
would mean writing code, and expecting bison to *ignore* that code.

Finally, as demonstrated by Paul Eggert, there are no (main stream)
programs that *could* ``exploit'' this bug (to be qualified, it takes
1. to require Bison, 2. to use the token error, and 3. include code
that should be ignored).

So *really* there is no point at all.

Now, if you insist on requiring the old behavior, then it is quite
easy to have an additional skeleton to keep the old behavior.  Say
bison.broken.  And then the user will be able to require this

But it is an additional burden on the maintainers, more documentation
to write, additional confusion for the users (since we will offer them
a choice which does not deserve to be considered).  Noone is winning

In any case, rest assured that once this bug fixed, the NEWS file will
contain a precise description of what was changed, plus pointers to
this thread.

reply via email to

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