Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E75B36C.6327581D@phekda.freeserve.co.uk>
Date: Mon, 17 Mar 2003 11:37:16 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: nmalloc revisited
References: <200303141601 DOT RAA26911 AT lws256 DOT lu DOT erisoft DOT se> <3E721051 DOT 645AA67D AT yahoo DOT com> <3E74B558 DOT 3629CBA9 AT yahoo DOT com> <1438-Sun16Mar2003203300+0200-eliz AT elta DOT co DOT il> <3E74E454 DOT BC734243 AT yahoo DOT com> <3E753E85 DOT 81830981 AT phekda DOT freeserve DOT co DOT uk> <3E755250 DOT 837B3606 AT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

CBFalconer wrote:
[snip]
> Following this (at the end) is the header file for malldbg, which
> is the module that will implement all of this.  The set of hooks
> are fundamentally flawed, and, while included, I also propose a
> set that will avoid those flaws.  For example, the existing
> realloc hook has no way of telling what the result of realloc
> was.

FWIW they look like they've been defined to be similar to the interfaces
provided by glibc. Was near-compatibility with the glibc interface one of the
goals, when the interface was designed?

As the libc docs say:

"`__libc_realloc_hook'
     Called at entry to `realloc', before the actual reallocation.
     BLOCK is a pointer 4 bytes before the address passed to `free' by
     the application, i.e. it is a pointer to the beginning of the size
     information maintained before the user buffer.  SIZE is the new
     size requested by the application.  (This hook is called _in
     addition_ to the other hooks which will be called by `free' and
     `malloc' if and when `realloc' calls them.)"

The __libc_malloc_fail_hook would be called, if the realloc call were actually
failing. So you can find out whether realloc fails, but not in the realloc
hook itself.

[snip]
> > Hint: you can get the test packages of DJGPP 2.04 made by Andrew, which
> > are available from here:
> >
> >     http://clio.rice.edu/djgpp/win2k/main_204.htm
> 
> Due to my innate crustiness etc., also the limitations of this
> system, I am not about to create a whole developent environment.
> And I have no idea what to poke at anyhow.  I have to rely on you
> guys for that.

You can get a recent snapshot of the malloc sources from djlsr204.zip
downloaded from the page above or get one of MartinS's CVS snapshots. The
sources are in src/libc/ansi/stdlib. Oh, and there's the include files
(libc/malldbg.h? Or more?). So you don't need to create a new development
environment, just to use the malloc from CVS. Just copy the files into some
work area

> Nobody has confirmed or denied that the html doc file I fed back earlier
> really covers the subject.

I confess I haven't looked at either MartinS's snapshot or the ZIP file you
sent.

> Maybe the following header will have better luck.
[snip]

Maybe you could provide a summary of the problems with the current hooks and
how your interface is better? What I can see so far:

Bad points:

* The realloc hook won't tell you whether realloc has failed. (This may not be
a problem, if you think the __libc_malloc_fail_hook is good enough.)

Good points:

* It has an extendable interface for setting the hooks.

* The paradigm for setting the hooks is a bit nicer, because it returns the
old hook value, instead of the user having to explicitly save it. Is there
some problem I missed here? This just seems like a way of saving typing  (=>
slightly less error-prone).

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]