Path: utzoo!utgpu!attcan!uunet!mcvax!hp4nl!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re: malloc bugs (s.b. Malloc bugs)
Keywords: malloc, Malloc, lmalloc
Message-ID: <621@philmds.UUCP>
Date: 25 Aug 88 06:41:32 GMT
References: <5919@batcomputer.tn.cornell.edu> <4120005@wdl1.UUCP>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 21

In article <4120005@wdl1.UUCP> dinolt@wdl1.UUCP (George W. Dinolt) writes:
    [amongst other things]...
>In fact the MWC compiler has an lmalloc(lsize) which takes a long as an
>argument, so in that compiler at least, there is no need to use Malloc.

It depends on where this lmalloc does its allocation. In Lattice C
malloc also takes a long as argument (an int being 32 bits in
Lattice).  Because the heap is lying between bss and stack the
available space for this malloc depends on what is allocated for the
program at startup time (by Mshrink); for instance a 'sh', a 'make', a
'find', a 'time' do have to leave room for other programs to exec in.
Then it can be profitable for a program to use both the system Malloc
and the C library's malloc.

I could however imagine a malloc that uses Malloc to reserve memory not
currently owned by the program... A clever one can even hide some of
the defiencies of the current Malloc (especially when it Malloc's in
big chunks so that it doesn't have to be clever too often, as
cleverness takes time 8-).

             Leo.