Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!linus!decvax!decwrl!ucbvax!anton From: anton@ucbvax.ARPA (Jeff Anton) Newsgroups: net.bugs.4bsd Subject: Re: Bug with Curses Message-ID: <9939@ucbvax.ARPA> Date: Fri, 16-Aug-85 14:02:33 EDT Article-I.D.: ucbvax.9939 Posted: Fri Aug 16 14:02:33 1985 Date-Received: Mon, 19-Aug-85 21:46:53 EDT References: <4966@mit-eddie.UUCP> Reply-To: anton@ucbvax.UUCP (Jeff Anton) Distribution: net.bugs.4bsd Organization: University of California at Berkeley Lines: 22 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