[net.bugs.4bsd] Curses bug

thomson (10/12/82)

Curses limits the total length of all string capabilities in a terminal
description to 128 characters, and fails in silent and strange ways if this
limit is exceeded.  The local manifestations were games of "rogue" that
would not die.  The only documented limit seems to be 1024 bytes for the
entire text of the description, so to be on the safe side we have increased
the string length limit to 1024 as well.
a
We run 4.1BSD; the change is in version 1.3 of file cr_tty.c (5/15/81)
where
	static char tspace[128],
becomes
	static char tspace[1024],

					Brian Thomson
					CSRG University of Toronto
					utcsrgv!thomson

jem (11/10/82)

I've found and fixed a bug in curses that occurred
when writing to a non-full-screen window, and is
terminal dependent.  It happens when curses tries
to get to a position in a window that starts to
the right of the current cursor position by printing
characters it expects to already be there.  It was
trying to print characters to the left of where
the window began, instead of filling in from curscr.
I'm not sure the fix is complete or even correct,
but it solved my problem.  My problem occurred
while trying to get 'et' (troll's editor) to work
on hp terminals.  Here's the diff fro cr_put.c:

258c258
< 				c = _win->_y[outline-_win->_begy][outcol-_win->_begx];
---
> 				c = curscr->_y[outline][outcol];

laman@sdcsvax.UUCP (Mike Laman) (11/12/83)

There is a bug in wdeleteln().  This bug is in the curses library distributed
over net.sources, and in the 4.2 BSD distribution (that sdcsvax received
at least).

Even though the last line of the window gets cleared internally, its "refresh"
image may not.  The fix is simple.  Add the following two lines to the end
of the wdeleteln() routine.

	win->_firstch[win->_maxy-1] = 0;
	win->_lastch[win->_maxy-1] = win->_maxx - 1;

Now wrefresh() will look at the entire line.

I have enclosed a little program that will show you if you have the bug.  Just
compile it with you curses library (termlib too) and run it.

#include	<curses.h>

main() {
	register i;

	initscr();
	mvaddstr(0, 20, "This program will delete line #5 after");
	mvaddstr(1, 20, "writing the line number for each line.");
	for(i = 0; i < LINES; ++i)
		mvprintw(i, 0, "Line #%d", i);
	refresh();
	addstr("     You have the bug if the BOTTOM line is not COMPLETELY blank!");
	move(5, 0);
	deleteln();
	move(LINES - 3, 0);
	refresh();
	endwin();
}

			Mike Laman
			UUCP: {ucbvax,philabs,sdccsu3,sdcsla}!sdcsvax!laman

laman@sdcsvax.UUCP (Mike Laman) (11/14/83)

I strongly suspect this fix didn't get out.  We got device full error messages
just when I posted this earlier this week.  Sorry, if you've saw the original.

There is a bug in wdeleteln().  This bug is in the curses library distributed
over net.sources, and in the 4.2 BSD distribution (that sdcsvax received
at least).

Even though the last line of the window gets cleared internally, its "refresh"
image may not.  The fix is simple.  Add the following two lines to the end
of the wdeleteln() routine.

	win->_firstch[win->_maxy-1] = 0;
	win->_lastch[win->_maxy-1] = win->_maxx - 1;

Now wrefresh() will look at the entire line.

I have enclosed a little program that will show you if you have the bug.  Just
compile it with you curses library (termlib too) and run it.

#include	<curses.h>

main() {
	register i;

	initscr();
	mvaddstr(0, 20, "This program will delete line #5 after");
	mvaddstr(1, 20, "writing the line number for each line.");
	for(i = 0; i < LINES; ++i)
		mvprintw(i, 0, "Line #%d", i);
	refresh();
	addstr("     You have the bug if the BOTTOM line is not COMPLETELY blank!");
	move(5, 0);
	deleteln();
	move(LINES - 3, 0);
	refresh();
	endwin();
}

			Mike Laman
			UUCP: {ucbvax,philabs,sdccsu3,sdcsla}!sdcsvax!laman