Re: Reductions during Bison error handling

[Akim Demaille]

>>>>> "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
skeleton.

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
here.

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.