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