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