Message-Id: <199710301211.XAA08640@mona.lexicon.net.au> Comments: Authenticated sender is From: "John Machin" To: Eli Zaretskii , djgpp AT delorie DOT com Date: Thu, 30 Oct 1997 23:09:38 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: malloc() References: <199710272358 DOT KAA01274 AT mona DOT lexicon DOT net DOT au> In-reply-to: Precedence: bulk > Date: Tue, 28 Oct 1997 10:49:08 +0200 (IST) > From: Eli Zaretskii > To: John Machin > 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