Bug 23912

Summary: vi(1) underflow of cnt in vs_paint() by O_NUMBER_LENGTH when both leftright and number options in use
Product: Base System Reporter: gladiatr <gladiatr>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: gonzo
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description gladiatr 2000-12-28 21:20:01 UTC 
in versions of nvi including the newer development versions, if the
leftright and number options are both active, the editor will dive into
a not-quite-inifinite loop.  in several seconds, it will return.  if 
the ruler option is active, it shows (1,4294967288).  nvi remains
fairly useless from this point forward and must be sigkill'd

Fix: this problem was traced back to vs_columns() returning a 0 value 
regardless of whether or not the number option is being used.

according to vi/vi.h, #define O_NUMBER_LENGTH 8

which should be the offset returned when 'set number' is active so 
that when the O_NUMBER_LENGH margin used for displaying the line number
is subtracted from the literal screen column, you will end up with 
column '0' rather than 0xFFFFFFF8.

Please note, I have read the comments towards the last nvi bug report
that was submitted here and understand that nothing will be 
done until the vendor commits the patch to their distribution.  I
thought it would be nice in case someone else has tried these two 
options in tandem and not had time to poke around to at least have a 
manual recourse.

I have submitted a bug report to Keith Bostic.  They are in the middle
of getting ready for a DB rollout, so it will be a while before he is
able to review the report.
How-To-Repeat: vi /your/favorite/file that is long enough to require a page redraw
: set leftright
: set number

<Ctrl>F a few times... (croak)
Comment 1 iedowse freebsd_committer freebsd_triage 2001-11-18 19:45:08 UTC 
State Changed
From-To: open->feedback


Does this problem still occur? I haven't been able to reproduce it.
Comment 2 gladiatr 2001-12-20 16:46:51 UTC 
Sorry if this is a repeat, but my previous follow-ups never made it into 
the PR:

 > Does this problem still occur? I haven't been able to reproduce it.

The answer to this is that it does indeed still exist.

Line 125 of contrib/nvi/vi/vs_relative.c is still doing the wrong thing.
Comment 3 Sheldon Hearn freebsd_committer freebsd_triage 2001-12-30 14:38:51 UTC 
State Changed
From-To: feedback->open

Originator says the problem still exists.
Comment 4 Sheldon Hearn 2001-12-30 14:42:39 UTC 
On Thu, 20 Dec 2001 08:50:02 PST, Stephen Spencer wrote:

>  Sorry if this is a repeat, but my previous follow-ups never made it into 
>  the PR:
>  
>   > Does this problem still occur? I haven't been able to reproduce it.
>  
>  The answer to this is that it does indeed still exist.
>  
>  Line 125 of contrib/nvi/vi/vs_relative.c is still doing the wrong thing.

Has Keith had time to review your report yet?

Ciao,
Sheldon.
Comment 5 gladiatr 2001-12-30 20:31:35 UTC 
On Sun, 30 Dec 2001, Sheldon Hearn wrote:

> On Thu, 20 Dec 2001 08:50:02 PST, Stephen Spencer wrote:
> 
> >  Sorry if this is a repeat, but my previous follow-ups never made it into 
> >  the PR:
> >  
> >   > Does this problem still occur? I haven't been able to reproduce it.
> >  
> >  The answer to this is that it does indeed still exist.
> >  
> >  Line 125 of contrib/nvi/vi/vs_relative.c is still doing the wrong thing.
> 
> Has Keith had time to review your report yet?
> 

I haven't heard back yet.  Perhaps I should resubmit the bug report.  It still
has not been fixed in the newer, development versions either.

Stephen Spencer | 
                |  "Come down off the cross. 
                |    We can use the wood..." 
                |                                T. Waits
Comment 6 Sheldon Hearn 2001-12-31 09:09:41 UTC 
On Sun, 30 Dec 2001 14:31:35 CST, "Stephen D. Spencer" wrote:

> > Has Keith had time to review your report yet?
> > 
> 
> I haven't heard back yet.  Perhaps I should resubmit the bug report.  It still
> has not been fixed in the newer, development versions either.

All we really need from keith is a "yes, we'll adopt your patch
verbatim" and we can commit it.

Ciao,
Sheldon.
Comment 7 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-07 14:06:56 UTC 
State Changed
From-To: open->analyzed

I'll commit the vendor-approved patch as soon as I have word back 
from <cvs@FreeBSD.org> on the best way to do this.
Comment 8 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-07 14:06:56 UTC 
Responsible Changed
From-To: freebsd-bugs->sheldonh

I'll take this one.
Comment 9 mheffner 2002-01-07 21:47:17 UTC 
For audit-trail:

Please see PR 33648 for followup.

Mike

-- 
  Mike Heffner     <mheffner@[acm.]vt.edu>
  Fredericksburg, VA   <mikeh@FreeBSD.org>
Comment 10 Sheldon Hearn freebsd_committer freebsd_triage 2004-02-17 11:19:07 UTC 
Responsible Changed
From-To: sheldonh->freebsd-bugs

Release.
Comment 11 Sheldon Hearn freebsd_committer freebsd_triage 2004-02-17 11:19:07 UTC 
Responsible Changed
From-To: sheldonh->freebsd-bugs

Release.
Comment 12 Sheldon Hearn freebsd_committer freebsd_triage 2004-02-17 11:19:07 UTC 
Responsible Changed
From-To: sheldonh->freebsd-bugs

Release.
Comment 13 Sheldon Hearn freebsd_committer freebsd_triage 2004-02-17 11:19:07 UTC 
Responsible Changed
From-To: sheldonh->freebsd-bugs

Release.
Comment 14 zhihao.yuan 2013-12-09 18:44:10 UTC 
Fixed long long time ago; please close.

-- 
Zhihao Yuan <zhihao.yuan@rackspace.com>
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/