Mail Archives: djgpp-workers/2002/10/23/00:24:11
> I am trying to make sure that this exchange contains a list of
> things needed to be done, so I have unsnipped a portion. Please
> keep it a massive whole, so I can eventually use it for review.
No :-)
The list I gave may not be exhaustive or perfect, I quickly hand
typed it in from looking at help files, headers.
In addition, I don't think it has to be done exactly the way it's
done today, as long as the functionality is the same and the
documentation is updated to reflect the way to do it, and
diagnostic helper routines/examples are provided.
The current CVS code has never been officially released, so unless
someone points out someone using the interfaces as written, I think
it's fair to discuss changes.
However, documentation and helper routines are already written, which
would lead me to the conclusion that what's there is best.
> The _sysquery call in nmalloc does just that - it returns
> sufficient information to completely scan the free list. Having
> made the call to get the info, the user is free to scan that free
> list at any time. In fact he can usually (but not always) scan
> all allocated blocks also. He can also follow the hidden linkages
> from any allocated block, including its actual size, physical
> neighbors, etc. All this involves *NO* run-time overhead. See
> the code in tnmalloc.c
There is no on-line help or detailed examples such as malldbg has;
so the how to is less clear. It needs to be something packaged
into a final product.
I would also suggest _sysquery isn't clear; maybe _malloc_query
or something would be better if retained.
(Note the current malloc() free is still broken, so we have to do
something, I'm just not sure what. And I'm on a 19.2K modem with
200ms latency, so I'm lucky to read email for the next 2 weeks).
My emergency fix is to stop looking for free merges after a short
search.
- Raw text -