[4215] in testers
Re: emacs 20.3/20.4 beta core dump
daemon@ATHENA.MIT.EDU (Richard Stallman)
Wed Jun 9 05:10:42 1999
Date: Wed, 9 Jun 1999 03:10:29 -0600 (MDT)
Message-Id: <199906090910.DAA05730@wijiji.santafe.edu>
From: Richard Stallman <rms@gnu.org>
To: jhawk@MIT.EDU
Cc: ghudson@MIT.EDU, testers@MIT.EDU
In-Reply-To: <199906070336.XAA27626@x15-cruise-basselope.mit.edu> (message
from John Hawkinson on Sun, 6 Jun 1999 23:36:02 -0400 (EDT))
Reply-To: rms@gnu.org
The obvious question is "Why it it adding 1 to find_before_next_newline()'s
result". The answer might be "Because find_before_next_newline() should always
return a position immediately followed by a newline, and the end of the buffer
is not necessarily a newline." Or not?
I think the reason is, that we want the position after the next newline,
and find_before_next_newline returns the position before it.
But the bug is when find_before_next_newline stops because of the end
of the buffer instead of before a newline.
shortage is indeed set to 1. Is the sense of this test wrong? I would assume
that if we found a shortage (scan buffer failed to find a newline), that we
want to return one less character than otherwise?
Certainly not! We should not give a subroutine a bizarre and incoherent
meaning, just to cause a certain caller to work!
I suspect that the right fix does not involve mucking with
find_before_next_newline(). I'm planning on trying to the following
workaround.
This seems like a clean fix. I will have it installed.
