Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ptsfa!pacbell!att-ih!chinet!dag
From: dag@chinet.UUCP (Daniel A. Glasser)
Newsgroups: comp.sys.atari.st
Subject: Re: dLibs v1.1 and SETPATH program
Message-ID: <3131@chinet.UUCP>
Date: 4 Mar 88 01:56:53 GMT
References: <350@stag.UUCP>
Reply-To: dag@chinet.UUCP (Daniel A. Glasser)
Organization: Chinet - Public Access Unix
Lines: 60
Summary: The truth about MWC malloc()

In article <350@stag.UUCP> syntel!dal@stag.UUCP (Dale Schumacher) writes:
[much omitted]
>> 	3) How reliable are the malloc() and free() functions
>> provided with MWC.
[more omitted]
>As for malloc() and free(), I can't comment on MWC's reliability, but I'm
>pretty sure that they allocate memory from the stack/heap area, which means
>that your program must ALWAYS reserve the maxiumum amount of memory that you
>ever will want to allocate.  The dLibs version allocates memory by requesting
>heaps through the system Malloc() call (carefully avoiding the bugs therein)
>and parcels out memory from those heaps with only 4-bytes overhead per call
>to malloc() instead of the typical 12-16 bytes.

The above is wrong.  MWC does not allocate from the stack/heap area.  If it
did, the system() call would not work.  The overhead per malloc is 4 bytes.
The malloc/calloc/realloc/sbrk (and l versions of the forementioned) use the
system Malloc() call, with a granularity to avoid the Gemdos Malloc bug.

[lots of stuff omitted]
>
>*WHEW*  Lots of stuff here...  Again in dLibs, there is a function called
>pfindfile() which will use the PATH to find a specified file (with one of
>a list of extension, if there is no extension).  It recognizes both ','
>and ';' as separators in the PATH list.  There is also a popen() function
>which works like fopen(), but uses pfindfile() to locate the file.  If
>applications used these functions, most of the above problems would be
>solved.
>
MWC provides the functions getenv() and path().  path() searches a selected
path (need not be PATH) for a particular file.  The "popen()" function
provided by dLib is useful, but its name conflicts with the popen() unix
function.  Some people may feel this is not a problem, but portability is
a major issue at MWC.  Rather than clutter up the documentation and
library with functions that are a simple combination of other functions
we let the user construct his/her own.

None of the above is to disparrage the work or comments of Dale Schumacher,
who has done the ST programming community a great service, and whos
contributions are appreciated by many, including myself.  I don't have
dLibs, I managed to miss it, but I find that his postings are usually
very useful.

MWC remains committed to providing a complete and robust library with
complete and accurate documentation.  The documentation does lag the
library, but we have only withdrawn one standard Unix library function,
crypt, from the library (it was never documented) since we first shipped,
and with each new release, the library becomes more populated.

>                Dale Schumacher
>                ..ihnp4!meccts!stag!syntel!dal
>                (alias: Dalnefre')

					Daniel A. Glasser
					M68000 product development
					Mark Williams Co.
					...{ihnp4 cbmvax}!mwc!dag

-- 
			   Daniel A. Glasser
...!ihnp4!chinet!dag || ...!ihnp4!mwc!dag || ...!ihnp4!mwc!gorgon!dag
    One of those things that goes "BUMP!!! (ouch!)" in the night.