Re: Possible bug in malloc-code

> In message <0be501c4474f$bb115400$471b3dd4_at_dual>, "Willem Jan Withagen"
writes:
> >
> >        i =         11
> >Alloc:  n =  335544320, ADR = 0x00000000485D7000
> >Alloc:  n =  402653184, ADR = 0x000000005C5D7000
> >Alloc:  n =  469762048, ADR = 0x00000000745D7000
> >Alloc:  n =  536870912, ADR = 0xFFFFFFFF905D7000
> >Free:   n =  536870912, ADR = 0xFFFFFFFF905D7000
> >rMemoryDrv in free(): error: junk pointer, too high to make sense
> >Abort (core dumped)
>
> As for this part:  Does the program in fact have a prototype for
> malloc(3) in sight ?  Can you try to explicitly add a wrong prototype
> to see that it complains ?  Alternatively, #include <stdlib.h> to get
> it a prototype.
>
> I looked briefly at the source code of the test-program and while I am
> in a position to say that it is doing something wrong with the casting,
> it does look mightily bogus to me.

Fair question, and to be honest. I assume(d) that it somewhere in its infinite
load of obscurity included stdlib.h

Hold on, I'll check....

Well I'm actually using calloc() since the original writer assumes that malloc
returns zero-ed space.

And looking through the preprocessed output stdlib.h is not included....

And bingo, we have a winner with stdlib.h manually included:

Alloc/Free large not inverse         11
Alloc:  n =  402653184, ADR = 0x00000000605E7000
Alloc/Free large not inverse         11
Alloc:  n =  402653184, ADR = 0x00000000785E7000
Alloc/Free large not inverse         11
        i =         12
Alloc:  n =  671088640, ADR = 0x00000000905E7000
Alloc:  n =  805306368, ADR = 0x00000000B85E7000
Alloc:  n =  939524096, ADR = 0x00000000E85E7000

No more sign-extention trouble

I'm afraid that these kinds of 'bugs' are going to haunt me for the remainder
of porting the tool. :(

Thanx,
--WjW