dpgerdes@osiris.cso.uiuc.edu (06/16/89)
/* Written 5:19 pm Jun 13, 1989 by rp@osc.COM in osiris.cso.uiuc.edu:comp.unix.microport */ >/* ---------- "Curses bug in V/AT 2.4 - what was i" ---------- */ >Hi, > I remember a couple of months ago that there is a bug in the >curses support under System V/AT ver. 2.4. Does anybody remember what it >was ?? Also, if anybody has a fix for it that would be appreciated. Please >either post or e-mail directly to me. > Don't know about the specific bug you are talking about, but the code below will die on just about any SysV out there. The problem, I believe, is that endwin() does not release allocated memory. #include <curses.h> main () { register int i = 0 ; while (++i) { printf ("Executing loop number: %d\r", i); initscr (); endwin (); } } On V/386 after about 90 some loops I get: Sorry, I don't know anything about your 'vt100' terminal.
keithb@reed.UUCP (Keith Brown) (06/19/89)
>is that endwin() does not release allocated memory. > >#include <curses.h> > { > printf ("Executing loop number: %d\r", i); > initscr (); > endwin (); > } It's not supposed to release the memory. endwin() just restores your tty to a sane mode so you can shell. As soon as you return from the shell, you may do a refresh() and poof, you've got your screen back, everything in place to continue executing. But one user having 90 of these, a bit beyond my remembering how far down the stack I am. -Keith -- Keith Brown UUCP: {decvax allegra ucbcad ucbvax hplabs}!tektronix!reed!keithb BITNET: keith@reed.BITNET ARPA: keithb%reed.bitnet@cunyvm.cuny.edu CSNET: reed!keithb@Tektronix.CSNET CIS: 72615,216
mem@zinn.MV.COM (Mark E. Mallett) (06/21/89)
In article <42700022@osiris.cso.uiuc.edu> dpgerdes@osiris.cso.uiuc.edu writes: > >/* Written 5:19 pm Jun 13, 1989 by rp@osc.COM in osiris.cso.uiuc.edu:comp.unix.microport */ >>/* ---------- "Curses bug in V/AT 2.4 - what was i" ---------- */ >>Hi, >> I remember a couple of months ago that there is a bug in the >>curses support under System V/AT ver. 2.4. Does anybody remember what it >>was ?? Also, if anybody has a fix for it that would be appreciated. Please >>either post or e-mail directly to me. >> Perhaps the message you refer to was a report of a bug in tgetstr(). I thought I had saved the original message, but I can't find it, so I can't say who it was that posted it. This bug must be compensated for to get running any program that uses it, including (for instance) JOVE. tgetstr()'s second argument is supposed to be the address of a pointer to a buffer. The bug is that it is implemented as if it is the actual pointer. For example, here's the workaround in JOVE's term.c module: ===== for (i = 0; meas[i]; i++) { #ifdef UPORT_CURSES_BUG *(meas[i]) = (char *) tgetstr(ts, termp); #else *(meas[i]) = (char *) tgetstr(ts, &termp); #endif ts += 2; ===== -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask (in mail!) about MV.COM
dpgerdes@osiris.cso.uiuc.edu (06/21/89)
/* Written 3:56 am Jun 19, 1989 by keithb@reed.UUCP in osiris.cso.uiuc.edu:comp.unix.microport */ > >It's not supposed to release the memory. endwin() just restores your >tty to a sane mode so you can shell. As soon as you return from the shell, >you may do a refresh() and poof, you've got your screen back, everything in >place to continue executing. But one user having 90 of these, a bit beyond >my remembering how far down the stack I am. > Well it looks I've been miss-interpretting this all along. I always understood it to imply that initscr() initializes curses and endwin() cleans up after itself. I have never seen the behavior above explicitly documented, but I just looked up the source and it agrees with what you said. Well I guess that provides and easier solution to my problem of entering and exitting curses. Thanks.