Mail Archives: djgpp-workers/2002/04/22/14:16:10
Charles Sandmann wrote:
>
> > 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 did qualify with apparent. It just seems to me that someone
somewhere would have compiled it and tried it out. Instead, dead
silence.
... snip ...
>
> 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.
I considered it, but did not test for it exclusively. I believe
there is nothing in the code to cause a problem, and there is a
comment about precisely that just above the actual nmalloc
function code. I have taken pains to do arithmetic with byte*
pointers, where byte is a typedef for unsigned char. The use of
sbrk is limited to the extendsbrk function, which also handles
alignment, and only cares whether or not the expected value is
returned. Unexpected values lead to greater fragmentation, and I
have never seen unexpected values under W98 AFTER initialization.
The initialization code appears to leave various little pieces in
odd corners, all of which is grist for the mill.
If anything were actually happening it would be trivial to add
just such a test to the fakesbrk generator in tnmalloc. As it is,
I shall avoid disturbing anything unless I decide a real bug
exists. It is hard to test/evaluate a moving target.
Notice that there is a serious realloc problem with the existing
code, as shown by the evilalgo program. I have not bothered to
look for the causes in the original, but have shown that the
problem does not remain in nmalloc. I did add the evilalgo source
to the zip file and some make targets.
--
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 -