Re: lib/53801: Segmentation fault in curses with pads

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

The following reply was made to PR lib/53801; it has been noted by GNATS.

From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/53801: Segmentation fault in curses with pads
Date: Sat, 5 Jan 2019 02:54:14 +0300

 On Wed, Dec 19, 2018 at 07:45:00 +0000, june@causal.agency wrote:
 
 > pad->cury and pad->curx get set in prefresh on refresh.c:485.
 > The LEAVEOK check above this seems inverted: the cursor position is
 > changed when LEAVEOK is *not* set.  The same appears in wrefresh.
 > The position calculation is copied from wrefresh and results in
 > coordinates outside of the pad bounds.
 
 No, the problem is that the window logic cannot be used for a pad as is.
 
 curscr->cury - win->begy is the offset from the beginning of the
 window.  The same code is used for the pad, but in pad's case the
 reference point should be sbegy and the result should be adjusted to
 take into account that sbegy is really pbegy.
 
 So it should be something like
 
     pad->cury = max(0, pbegy + (curscr->cury - sbegy));
     pad->curx = max(0, pbegx + (curscr->curx - sbegx));
 
 modulo more checks.  That doesn't crash, but it doesn't really do the
 right thing either b/c there's a probably a similar pad vs window
 problem elsewhere and we end up with wrong curscr->cury
 
 E.g. tweaking the test to be a bit more complex:
 
     WINDOW *pad = newpad(2, COLS);
     mvwaddstr(pad, 0, 0, "Hello\nWorld");
     prefresh(pad,
         1, 0,		/* pad start position */
 	5, 0,	        /* screen start position */
 	5, COLS - 1);   /* screen limit */
 
     int y = -1, x = -1;
     getyx(pad, y, x);
 
 gives expected (1, 5) under ncurses but (0, 5) under netbsd with the
 above change (curscr->cury is 0, so a negative value is caught by the
 max), and the cursor is in the first line after the refresh, not the
 6th line.
 
 -uwe