Mail Archives: djgpp-workers/2003/03/18/09:49:02
Eli Zaretskii wrote:
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
> >
... snip ...
>
> > 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?
I would be glad to try something else, if anyone can propose it.
Meanwhile note that the _malloc name etc are limited to the files
hookmem.h, malldbg.c, and (only when HOOKABLE is defined)
nmalloc.c. The three names are easily changed to something else
if conflicts arise. They do not propagate onward, except as the
linker handles them. Eventually the two .c files can be combined,
with the malldbg portion enabled only by HOOKABLE, and the name
pollution can disappear.
Meanwhile the purpose is to avoid disturbing proven (to me) code
with new code.
As far as the realloc hooks are concerned, nmalloc NEVER calls
free or its equivalent in many circumstances, even when the
contents are moved. It also never calls malloc. Any such
indication would be a distortion. Thus I am providing a
realloc_exit hook, when the net effect can be detected. The
internal tables are already consistent. Something external is
free to assume that the original is freed and the new malloced,
although that does not reflect reality.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -