Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mimsy!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c,comp.unix.questions Subject: Re: A little prob with curses. Message-ID: <6067@brl-smoke.ARPA> Date: Mon, 6-Jul-87 00:22:35 EDT Article-I.D.: brl-smok.6067 Posted: Mon Jul 6 00:22:35 1987 Date-Received: Mon, 6-Jul-87 06:47:39 EDT References: <1032@killer.UUCP> <6050@brl-smoke.ARPA> <784@nu3b2.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 21 Xref: mnetor comp.lang.c:2848 comp.unix.questions:3094 In article <784@nu3b2.UUCP> rwhite@nu3b2.UUCP (Robert C. White Jr.) writes: > I is important to note that curses simulates "many of the older >termlib functions for compatibility reasons" This is true of the terminfo-based libcurses, first shipped with SVR2.0, but NOT of the older termcap-based libcurses, for which one has to also link in libtermlib as I said. > If you are using a system like mine [3B2/310 SVR2.0.4+] you may find >that some libraaries [malloc/signal/and some others] are/arn't being loaded >because of internals. make shure that you have #included if you >use the calls, if you do try it with and without -lmalloc [etc...] I think you're going to confuse people with this. The old standard malloc()/free()/calloc()/realloc() functions are still found in the standard C library. defines some stuff specifically for libmalloc, which is an OPTIONAL "improved" version of malloc that includes some additional routines. should NOT be used unless you plan to make use of the additional routines. Otherwise whether or not to link in libmalloc should not matter except perhaps as a matter of run-time efficiency.