Mail Archives: djgpp-workers/2002/04/22/00:07:15
> I put a whole bunch (of benchmarks) up earlier using a/b
> comparisons on my machine with some of my software. I am
> impressed by the apparent NIH syndrome, and am not especially
> motivated to contribute further efforts. This is the first time
> anyone has shown any signs of even reading the code
Please be patient. At least in my case, this isn't a NIH syndrome
(I'm quite happy replacing anything I've ever written, even actively
suggest it ...) but a case of time. If you check the DJGPP workers
discussions, you will find some dicussions on less significant
parts of the libc have gone on for months before getting finalized.
I'm sorry if you believe that I have ignored you - but back in January
I promised several people I'd get a refresh++ out (a few include
fixes, updated dsm, readme, etc) and I still haven't gotten around to
it. That would be a higher priority, and it is now 3.5 months beyond
that. It's quite possible I wouldn't get to a new malloc review for
another few months (it's been a busy year for me).
There are a small number of workers who are interested and comfortable
reviewing major pieces like malloc() - and unfortunately most of them
are exceptionally busy. Windows 2000 bugs broke DJGPP very badly,
but it took us 2 years to get a refreshed release out to fix it - and
most binary packages still haven't been rebuilt.
V2.04 (which would be when the new malloc package would be released)
is several months away - and would be further if Andrew didn't post
big rebuilds of packages using the CVS tree to find and debug things.
Please don't be discouraged from your contribution's slow pace. If
you were to go away today and never come back I'd probably eventually
review/tweak the code to get it into CVS myself. The free problem is
a real one due to a poor algorithm, and I appreciate you taking the
time to look at it and provide a fix. Sticking around and bugging
gently will help it get done more quickly, and you can help us
provide a higher quality product.
That still doesn't mean I think it's time to check it in without more
testing. In particular, I don't know what would happen if you got
a sbrk() sequence that looked like:
0x00010000
0xfffd0000
0x00020000
0xfffe0000
In other words, addresses which are not strictly increasing, and can
include values which mess up signed/unsigned comparisons, and can mess
up sizing quite a bit. This sequence above can be caused under Windows
in the right conditions. If we haven't tested in that case, I'd be
scared to release it - since it has broken previous malloc() packages.
- Raw text -