Mail Archives: djgpp-workers/2003/03/18/01:43:04
> Date: Sun, 16 Mar 2003 23:42:56 -0500
> From: CBFalconer <cbfalconer AT yahoo DOT com>
>
> For example, the existing realloc hook has no way of telling what
> the result of realloc was.
The other hooks that get called inside realloc and its subroutines do
that job.
> In addition the specifications have magic numbers, which
> have no relationship to reality for this system.
What magic numbers? If you mean the 4-byte overhead and such, then
the documentation mentions that because it tries to give all the
details pertinent to debugging malloc-related issues. If the details
of your implementation are different, you should revise the
documentation accordingly. There's no intent, of course, to insist on
4-byte overhead/offset in an implementation that manages the memory
pool in a different way.
> Nobody has confirmed or denied that the html doc file I fed back
> earlier really covers the subject.
Sorry, I don't have time to open binary attachments and/or launching a
Web browser to read them. Could you possibly send that as plain text
that is part of the message body? Then I promise I'll read and
respond.
TIA
> I have modified (but not published yet) nmalloc to allow use of
> the HOOKABLE define, which basically modifies the access points
> from malloc to _malloc, etc.
I'm not sure renaming standard functions is a good idea. There are
development tools out there (e.g., GDB) that _depend_ on their
knowledge of some of these fucntions. If we have __malloc instead of
_malloc in our symbol table, these tools might become confused.
Isn't there some other way of providing hooks?
- Raw text -