Mail Archives: djgpp-workers/2003/03/14/11:01:57
CBFalconer said:
> Martin Stromberg wrote:
> > > BTW the nmalloc.c code has not been altered since June 2002, and
> > > the overall package is unaltered since November 2002 (some
> > > documentation changes and testing). It remains available at:
> >
> > So it remains incompatible with the debugging machinery already
> > present in DJGPP?
> >
> > I'll back out my local incorporation of it as it seems it never will
> > be (and some DJGPP test case(s?) won't build).
>
> What won't build? I have never found any specification for the
Some test case in djgpp/test. I don't remember exactly where but
tests/libc/ansi/stdlib/ is not impossible. It tried to use the malloc
debug hooks.
> debugging systems, but the debug interface remains in nmalloc,
You can't be using up-to-date information. It's checked in in CVS. You
can get a current version of malloc.txh here:
<http://www.ludd.luth.se/~ams/djgpp/cvs/djgpp/src/libc/ansi/stdlib/>.
> You can see the dramatic effects by trying evilalgo.c, or by
> executing test 4 of the hashlib package for something like 40000
> allocations. nmalloc cuts the running time of that test by about
> a factor of 60, all spent in the free routine.
I agree that the current implementation has some problems. I think
all on this list do so too and have for a long time.
Your implementation has worked well for me (except for that test case
above, which currently can't work). But I've mostly been rebuilding
libc and the other DJGPP specific programs so I'm not sure that my
environment is sufficiently stressful.
Somebody needs to either rework your code into what's in the
documentation or vice versa. That somebody doesn't exist. It's
unlikely he'll appear. It's been like this a year or so.
Hence, we will probably just patch up the current malloc implemention
to avoid that evilalgo problem (not perfectly but workingly).
Right,
MartinS
- Raw text -