Date: Thu, 30 Jan 1997 09:58:48 +0200 (IST) From: Eli Zaretskii To: "A.Appleyard" cc: DJGPP AT delorie DOT com, Mark Wodrich Subject: Re: A misfeature re malloc() and new In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.