[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/53801: Segmentation fault in curses with pads
The following reply was made to PR lib/53801; it has been noted by GNATS.
From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
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, email@example.com 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");
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
Main Index |
Thread Index |