Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E7616BC.E333FA24@phekda.freeserve.co.uk>
Date: Mon, 17 Mar 2003 18:41:00 +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> <3E75B36C DOT 6327581D AT phekda DOT freeserve DOT co DOT uk> <3E75E6E1 DOT A3989CD6 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:
> 
> Richard Dawe wrote:
> > 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?
> 
> They have.  I would not have designed them that way.

Um, I was hoping the original designer would answer that question. I believe
that was Eli. Eli?

> >
> > 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.
> 
> There is a big fallacy here - i.e. that malloc and free are
> actually called.  This is not so for nmalloc, although it does
> call some of the same routines.  realloc is designed to avoid
> moving data whenever possible.  Nothing in the standard requires
> this either.  The end effect is the same.

DJGPP CVS does it one way. You implementation does it another way. To say it's
a fallacy is a bit strange, given that the text above is talking about the
CVS, where it is true. You are comparing apples with oranges.

[snip]
> > 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
> 
> No, I can't use the existing malloc.  That is the whole reason for
> this development in the first place.  On principal, subsystems
> should be developed in isolation, but checked in the overall
> system.
[snip]

You said:

"I developed nmalloc to satisfy the well published and known standard
interface, and got people screeching about failure to mate with other modules.
I finally found a definition of those modules, and am even attempting to
provide something close, but now you tell me those are for the inner-sanctum
only and are not even published."

I was pointing out where you could get the the definition of the standard
interface from: the code in CVS.

I don't have enough time to look at nmalloc, so I'm not going to say anything
further.

Bye, Rich =]

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