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.