Message-Id:	<199710301211.XAA08640@mona.lexicon.net.au>
Comments:	Authenticated sender is <sjmachin AT mail DOT lexicon DOT net DOT au>
From:	"John Machin" <sjmachin AT lexicon DOT net DOT au>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com
Date:	Thu, 30 Oct 1997 23:09:38 +1000
MIME-Version:	1.0
Subject:	Re: malloc()
References:	<199710272358 DOT KAA01274 AT mona DOT lexicon DOT net DOT au>
In-reply-to:	<Pine.SUN.3.91.971028104653.22947N-100000@is>

> Date:          Tue, 28 Oct 1997 10:49:08 +0200 (IST)
> From:          Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
> To:            John Machin <sjmachin AT lexicon DOT net DOT au>
> Cc:            djgpp AT delorie DOT com
> Subject:       Re: malloc()

> 
> On Tue, 28 Oct 1997, John Machin wrote:
> 
> > This could be fixed, but I am puzzled why DJ hasn't snarfed a better
> > malloc from somewhere -- I understand his comments about GNU GPL
> > that he made in a posting, but what about public-domain stuff???
> 
> The version of `malloc' in the current libc *is* public domain: it's
> from the BSD library.  GPL'ed code is not good enough for DJGPP's
> libc, because libc needs to be free, not GPL'ed.

As I said, I *understand* DJ's comment about GPL; and yes, I have 
read the comments in the source files often enough to note that large 
chunks of libc are from BSD. Perhaps I should have said "what about 
_other_ public domain stuff?".

>  Most of the
> ``better'' allocators (at least those I'm aware of) are either
> GPL/LGPL or have other non-free distribution policies.  If you know
> about a place where gobs of public-domain allocators are available,
> please tell where that place is.

There _was_ a URL for one public-domain allocator (Doug Lea's) later 
in the original message. "Gobs"? One good one should be enough ...

> 
> > Pardon me if this has been considered and rejected it for 
> > reasons that I can't guess, but I'd suggest that "Doug Lea's malloc" 
> > would be a good substitute. I got it off the web, whacked in a few 
> > #defines, compiled it, and happiness prevailed; see below which is 
> > the first few lines of the source file with my changes and his 
> > "advertisement" and URLs.
> 
> Thanks for your suggestion.  However, your message makes it sound
> much easier than it really is.
> 
> Past experience of DJGPP development suggests a simple truth: it is
> not enough to ask ``why not'' questions such as this, or even see
> that a given library compiles with DJGPP after some hacking.
                                                      ^^^^^^^
There was no "hacking" required, only a careful reading of the 
copious comments about the various #defines to see which ones 
required non-default settings for DJGPP.

>  To
> replace a functionality as central as `malloc' requires that
> somebody actually sits down, understands the features and
> limitations of both the original and the replacement, makes some
> comparative tests of the two, and posts the results for a review. 
> Dumping a bunch of #ifdef's into a message and asking others to do
                                                 ^^^^^^^^^^^^^^^^^^^
> the actual work doesn't help a bit.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Please forgive me, but I'm at least one of "drunk, insane, or 
Australian" ... having re-read my message a few times, I can't see 
where I have asked others to do any actual work.

> It would help a lot more if you
> would volunteer to integrate the replacement `malloc' into the
> library, including any necessary changes in the headers and the libc
> reference docs, then submit the patches to DJ Delorie (who maintains
> the library). 

So far I have tested various programs of my own with (a) the DJGPP 
malloc (b) my fix of that malloc to avoid the gross wastage cases (c) 
Doug Lea's malloc. Where they did not run out of memory, the results 
were identical. (c) runs out of memory much later than (a) and (b).
I am happy using Doug Lea's malloc for my own purposes. However 
recalling that I've got a lot out of DJGPP, and also that it enabled 
my wife to complete her thesis on a 486 at home instead of fighting 
traffic and/or the telco to get the chance to fight with myriads of 
others for a slice of some *n*x box at the University, I thought I 
might contribute something back.

First I thought I had better wave my kerchief about a little to see 
if anyone took any _meaningful_ potshots at it.

Here's another wave: 

1. DL's malloc is easy to find (Altavista +malloc +source gave among
others a web page that had pointers to several allocators, including
DL's.) 

2. The source of DL's malloc has the look and feel of good solid
code, is said to be included as the default malloc in some Linux
distributions, seems (to me) to work OK, is public domain (according
to the comments in the source), has no copyright notice in it, ... 

3. Sounds too good to be true ... so, before I spend a lot of time
testing it etc, is there anybody out there who has actually bothered
to investigate this allocator?

Anybody know of a good malloc/free test suite?

Anybody care to define acceptance criteria for a 
malloc/free/calloc/realloc implementation?

> 
> (Of course, I'm assuming that the distribution terms live up to the
> ``public domain'' definition.  The fine print could tell otherwise.)

"The code for this allocator has been placed in the public domain". 
There are NO restrictions or copyright notices mentioned in the 
source file. Read it and see for yourself. 


John Machin
1/27 Auburn Grove
Hawthorn East, VIC 3123, Australia
Phone: +61-3-98130561

- Raw text -