stopgap measure to make vi recovery mostly functional on non-binary files.
The problem is that the db holding the recovery file can become corrupted,
in which case the data size of the line becomes huge. We use heuristics to
correct the size when we load a db in recovery mode. We could use a slightly
better heuristic (looking for ascii chars before correcting the length),
but it is not worth it. Another way would have been to trap the SEGV and
access data[len] and see if that worked, but that seemed exceedingly ugly.
a second time. Checking for the plain temp filename was not enough,
as it may be set even though we are calling the function for the
first time.
fixes bin/15474 by Chuck Cranor
by defining the (newer) CUT_LINE_TO_EOL define in common/cut.h and using it
where due.
Bug reported on current-users by Masanori Kanaoka <kanaoka@ann.hi-ho.ne.jp>
diagnosed by Bang Jun-Young <bjy@mogua.org>,
quick-fixed by Robert Elz <kre@munnari.OZ.AU>.
(and use ENTIRE_LINE instead of 0 where appropriate)
This fixes a bug in the dw command with for example:
<cursor>
a b c
~
~
if you hit dw there, only the empty line would be killed but both the empty
line and the subsequent one would be pasted when asked for with P for example.
because of a weird umask for example.
Make it exit instead.
This differs from the OpenBSD behaviour and is believed to be more correct.
Reported by Thomas Klausner in private e-mail, followed by a small discussion in
tech-userlevel a while ago.
- ensure hostname from gethostname() is nul-terminated in all cases
- minor KNF
- use MAXHOSTNAMELEN over various other values/defines
- be safe will buffers that hold hostnames
christos