From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10210210402.AA21746@clio.rice.edu>
Subject: Re: CBFalconer's malloc
To: djgpp-workers AT delorie DOT com
Date: Sun, 20 Oct 2002 23:02:20 -0500 (CDT)
In-Reply-To: <3DB32764.292952DC@yahoo.com> from "CBFalconer" at Oct 20, 2002 06:00:04 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Glad someone is looking at it.  

We have a few problems...

The code is significantly different from the current documentation and
user interfaces in CVS/V2.04.

The following external interfaces are missing:
 mallinfo
 malloc_debug
 malloc_verify
 mallocmap
 __libc_malloc_hook
 __libc_malloc_fail_hook
 __libc_free_hook
 __libc_free_null_hook
 __libc_realloc_hook
 __malloc_get_freelist
 __malloc_get_slop
 __malloc_get_bytes_in_use
 __malloc_get_chunks_in_use
 __malloc_get_sbrked
 
These will need to be added, or alternate debugging routines written and
documented.  It appears retrofitting CBF's code with the above routines
would be the right thing to do (but is fairly substantial work).

There is also the question of stress testing the code.  The easiest 
thing to do would be to fix the bare minimum naming to be libc compatible,
dump it into a copy of libc.a, and try building the entire toolchain
twice to see if all goes well.  This would need a volunteer ...