simsong@mit-eddie.UUCP (Simson L. Garfinkel) (08/13/85)
Replace this line with your message
simsong@mit-eddie.UUCP (Simson L. Garfinkel) (08/13/85)
Hello? I've been using Curses at a number of different cites on both VAXen and suns. It appears that any application linked with curses core-dumps if the screen is more than 80 col. wide. Has anybody else run into this? Does anybody know what the fix is? The only mention of 80 anywhere in the source code that I can find is in cur_c.c: if (COLS <= 4) COLS = 80; I refuse to believe that this would make the program dump at wider screens. Confused, Simson L. Garfinkel
mouse@mcgill-vision.UUCP (der Mouse) (08/16/85)
> It appears that any application linked with curses core-dumps if > the screen is more than 80 col. wide. > Has anybody else run into this? Yes, we have. If anyone has a fix please send it to us as well! -- der Mouse {ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse philabs!micomvax!musocs!mcgill-vision!mouse Hacker: One responsible for destroying / Wizard: One responsible for recovering it afterward
anton@ucbvax.ARPA (Jeff Anton) (08/16/85)
In article <4966@mit-eddie.UUCP> simsong@mit-eddie.UUCP (Simson L. Garfinkel) writes: >I've been using Curses at a number of different cites on both VAXen and >suns. It appears that any application linked with curses core-dumps if >the screen is more than 80 col. wide. This is a curses bug that I spotted sometime ago. The problem relates to how windows are scanned for differences. It seems that curses does not bother to check when it's compairing past the end of the window. As a rare case, if the window space malloced is close to the end of memory you might get a seg fault as the scanning routine runs of the end of data space. A kludge fix to this problem is to place after initscr and newwin calls a 'malloc(1);'. This will insure that the data after the screen will cause the scan to stop before running out of data space. (I know there is a billion to 1 chance this isn't true) I think the bug is fixed in 4.3, but I will continue defensive programming for a long while to come. -- C knows no bounds. Jeff Anton U.C.Berkeley ucbvax!anton anton@berkeley.ARPA
zap@ttds.UUCP (Svante Lindahl) (08/21/85)
In <4966@mit-eddie.UUCP> simsong@mit-eddie.UUCP (Simson L. Garfinkel) writes: > [...] >I've been using Curses at a number of different cites on both VAXen and >suns. It appears that any application linked with curses core-dumps if >the screen is more than 80 col. wide. > >Has anybody else run into this? Does anybody know what the fix is? The >only mention of 80 anywhere in the source code that I can find is in >cur_c.c: > > if (COLS <= 4) > COLS = 80; > [...] Today I got my new terminal, a Facit Twist, which can be used as a regular vt100, or, if you twist the screen, like 72-line VT100. (Now I can write loooong functions and still fit them on one screen :-) Turns out that some (all?) programs linked with curses dumps core when the terminal type is set to twist... Seems like the designers of curses weren't visionary enough (``Gee, - they'll never make terminals any bigger than 80x24''). Or am I wrong? I hope so, and that there is an easy fix, 'cause I don't wanna have to change terminal type each time I run a cursed :-) program. -- Svante Lindahl, NADA, KTH (Dept of Numerical Analysis and Computer Science at the Royal Institute of Technology) UUCP: {seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc,unido}!enea!ttds!zap ARPA: enea!ttds!zap@seismo.ARPA or Svante_Lindahl_NADA%QZCOM.MAILNET@MIT-MULTICS.ARPA
zap@ttds.UUCP (Svante Lindahl) (08/23/85)
In article <1019@ttds.UUCP> I wrote: >Turns out that some (all?) programs linked with curses dumps core >when the terminal type is set to twist... When I relinked ``top'' with the version of curses that came on net with the window package ``wm'' it works OK. -- Svante Lindahl, NADA, KTH (Dept of Numerical Analysis and Computer Science at the Royal Institute of Technology) UUCP: {seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc,unido}!enea!ttds!zap ARPA: enea!ttds!zap@seismo.ARPA or Svante_Lindahl_NADA%QZCOM.MAILNET@MIT-MULTICS.ARPA