jpn@teddy.UUCP (John P. Nelson) (10/04/88)
Reply-to: jpn@teddy.UUCP (John P. Nelson)
We just brought up Ultrix 3.0. I can't believe it: curses is STILL broken.
I have reported this bug for every release of ultrix since (and including)
1.1. I don't know why my bug reports are getting tossed into the wastebasket,
but I don't think anyone at DEC is listening! I have just asked my system
administrator to submit another bug report, but perhaps someone at DEC reads
this newsgroup!
The Ultrix "curses.h" has a bug in the definition of the nl() and nonl()
functions. In fact, the header has comments showing how some dec programmer
"fixed" it (it's quite clear he didn't understand it).
The following program demonstrates the bug:
/* demontration of the ultrix curses bug */
#include <curses.h>
main()
{
initscr();
nonl();
move(5,0);
printw("line five, column 0");
move(6,0);
printw("line six, column 0");
move(12,0);
refresh();
endwin();
}
/* end of program */
Dec defines the macros this way:
#define nl() (_tty.sg_flags |= CRMOD,_pfast = _rawmode,NONL = 0,stty(_tty_ch, &_tty))
#define nonl() (_tty.sg_flags &= ~CRMOD, _pfast = TRUE, NONL = 1,stty(_tty_ch, &_tty))
However, they SHOULD be defined as:
#define nl() (_tty.sg_flags |= CRMOD,_pfast = _rawmode,stty(_tty_ch, &_tty))
#define nonl() (_tty.sg_flags &= ~CRMOD, _pfast = TRUE, stty(_tty_ch, &_tty))
Changing the NONL variable is just plain WRONG. "NONL" is used to hold
the state of NL mapping BEFORE the program started, and is assumed to
indicate how the TERMINAL responds to newline characters. The _pfast
variable is used to determine the CURRENT mapping!
This change would bring the ULTRIX "curses.h" back in line with every other
BSD "curses.h". Come ON dec, I keep having to fix this with EVERY RELEASE!
--
john nelson
UUCP: {decvax,mit-eddie}!genrad!teddy!jpn
smail: jpn@teddy.genrad.com