Mail Archives: djgpp-workers/2003/03/17/13:41:25
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/ ]
- Raw text -