Date:	Mon, 21 Oct 2002 08:08:38 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp-workers AT delorie DOT com
Subject:	Re: CBFalconer's malloc
In-Reply-To:	<3DB390CF.3431DC36@yahoo.com>
Message-ID:	<Pine.SUN.3.91.1021021080256.17080D-100000@is>
MIME-Version:	1.0
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

On Mon, 21 Oct 2002, CBFalconer wrote:

> > 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).
> 
> I made provisions for getting at the internal structure, and used
> an example of it in the dumps from the testing code.  If you will
> give me the details of what those interfaces have to do I will see
> (no promises) how they can be generated.

IIRC, all those interfaces, or at least those which are intended to be 
for public use, are documented in the library reference (see malloc.txh 
in CVS).

> The point to me is that
> any such interfaces are done through header files, and leave the
> malloc code itself free to do what it needs.

I'm not sure I understand.  The debugging hooks are called by malloc at 
strategic places, provided that they are non-NULL (each hook is a pointer 
to a function, by default set to NULL).  malloc is free to do what it 
needs, but it must call the hooks while it's doing that.

- Raw text -