Re: Bug: Searching through sufficiently large $historywords causes seg fault

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

> On 10/05/2023 00:05 Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Tue, May 9, 2023 at 12:01 PM Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
> >
> > On Tue, 2023-05-09 at 09:58 -0700, Bart Schaefer wrote:
> > >
> > > Scratch that ... I had not correctly recompiled.  After correctly
> > > recompiling, I can't reproduce the segmentation fault at all with
> > > 51722, but the event added with "print -S" is entirely missing from
> > > $historywords even though it is found when scrolling the history.
> >
> > That sounds fine --- it's the division into words, not the line, that's
> > causing the problems which this avoids.
> 
> It's fine that an event is missing from historywords?  Doesn't that
> mean that we've just skipped over the problem code rather than figure
> out why it's wrong?

The current patch is entirely about safety to cover all the possible
cases where history word numbering is going wrong and preventing crashes.
Completion is particularly sensitive to this as it looks at all words
for all lines, so if it can go wrong, it will.  The patch now seems to
be doing its job.

Tracking down all possible cases where a history word number can be
calculated wrongly from any possible source is another thing entirely.
Possibly some DPUTS() in the earlier code are a good idea, as now we
know it is showing up in error later on trapping it there isn't going
to help any more.

pws