Date:	Thu, 30 Jan 1997 09:58:48 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk>
cc:	DJGPP AT delorie DOT com, Mark Wodrich <mwodrich AT ct DOT lia DOT net>
Subject:	Re: A misfeature re malloc() and new
In-Reply-To:	<BE4B552ED7@fs2.mt.umist.ac.uk>
Message-ID:	<Pine.SUN.3.91.970130094542.17132M-100000@is>
MIME-Version:	1.0

On Wed, 29 Jan 1997, A.Appleyard wrote:

> > You have checked the source, so I bow to your superior knowledge, BUT: How
> > can this be? The more I hear about djgpp's malloc, the more I shudder! Is
> > this "standard" GNU implementation of malloc/free? It seems horribly
> > wasteful....

The DJGPP malloc is NOT from GNU sources.  None of the C library is, 
because that would make DJGPP-compiled programs fall under the GNU 
License, which is sometimes too restrictive for commercial programs.  See 
chapter 19 of the DJGPP FAQ list for details.

The code for DJGPP malloc and friends comes from the BSD Unix library
(which is public domain). 

As for malloc, this issue keeps popping up from time to time, but my
humble opinion is that it is certainly not as horible as it might sound. 
Many people (me included) have said that the algorithms there are not
optimal (to say the least) for the DJGPP environment, but I have yet to
see an example program that displays a ``horrible'' behavior as indicated
by the algorithm deficiences, and a patch to malloc which will make such
horrible behavior go away.  If so many people dislike malloc so much, how
come nobody has stepped out to work on it?  Perhaps it's not so horrible
after all? 

>   djgpp's heap needs a garbage collecter. I could write one easily; but it
> would need to know the whereabouts of <all> pointers-to-heap that may need to
> be updated during the garbage collection.

AFAIK, this is close to impossible for a C program, due to the 
pointer-aliasing problem, even if you are talking about garbage collector 
that doesn't relocate blocks.  A relocating garbage collector is AFAIK 
only possible in C++.

>   Of the functions and subroutines declared by these #includes, which use the
> heap?: ctype.h dpmi.h fcntl.h go32.h new.h pc.h setjmp.h std.h string.h
> sys/exceptn.h sys/farptr.h sys/stat.h time.h

You will have to grep the library sources.  `stat' certainly uses 
`malloc', and some of the _go32_XXX functions also.

>   The matter which is automatically obeyed before main() is called: does it
> use the heap?

The startup code also uses malloc to expand the command-line arguments 
and store the environment.

- Raw text -