Mail Archives: djgpp-workers/2003/04/20/13:45:21
> Date: Sun, 20 Apr 2003 10:14:04 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
>
> When I combine it into a single module, it will work exactly as
> you described it if mounted in the library. The hook pointers
> will be NULL, and can be set directly.
Then please reiterate why is it necessary to define `malloc', `free',
etc., which are standard functions, in your version of malldbg.c, and
have them call `_malloc', `_free', etc. Will this go as well when
nmalloc is part of the standard library?
> To address Charles Sandmanns concern over the documentation, I
> have implemented it exactly to the existing documentation, with
> the exception that malloc_debug has an additional FILE* parameter
> to set the file on which to display results. If that is NULL
> stderr is used. Easily changed back to eliminate the FILE*, and
> add a new name or macro for that functionality.
That's okay, but the additional functionality--the ability to control
where the messages go--needs to be documented.
> If all goes well with this I can rework to remove the loading of
> malldbg code unless the application specifically links to it.
Please tell the details. Does the user needs to do anything besides
calling function(s) in malldbg? I'd like to avoid any additional
requirements.
> What I envision is that the sysquery.h header will be expanded
> slightly, so that externals can discover the address of the above
> set_m_hook and the corresponding enum. The malldbg module will
> use this to sink its own hooks. The piece of information holding
> the heads of the "unexpected" sbrk chains will also be moved into
> malloc proper, and its location exposed through sysquery.h and the
> _sysmalloc call, thus hidden from prying. Without including
> sysquery.h the whole system is immune to accidents from valid
> code. With sysquery.h it is wide open. #including <malldbg.h>
> allows malldbg.o to be loaded, which calls sysquery etc.
It is not quite clear to me how this will work. Please elaborate, or
post an example.
> According to me there are no bugs, but I have been known to be wrong
> about that before.
Being bug-free is not a requirement for code to be included in the
library ;-)
> As I said earlier, the semantics of the various debug_levels need
> to be thrashed out.
Again, let's talk about the details.
- Raw text -