Mail Archives: djgpp-workers/1999/06/25/20:35:02
> > I did some experimenting and printed out the addresses coming from
> > malloc-calls in CC1.EXE, there were several hundreds of them, and
> > some of them were below 2 Gbyte, and some were above 2 Gbyte,
> > it all came out in a random fashion.
>
> Not unexpected if you get some dpmi blocks returned below the
> original one.
No it's perfectly ok in theory, and malloc and CC1.EXE should work
just as well for any pointer between 1 and 4 Gbyte-1, in theory.
Maybe there is an error in win3.11:
Too many DPMI-requests with unordered blocks in one
program could perhaps overflow the internal Windows tables,
and it's not indicated in the CF-flag from the DPMI-call.
That's just a theory. It might also be malloc, realloc or GCC.
Just some other experiments that I did recently:
1) I made an "improved" malloc.c (malloc, realloc, free),
which calls the old malloc, realloc, free, but also inits
malloc'ed data to 0 and also copies the old
data in realloc to the new address. I rebuilt CC1.EXE
with it and it seems to work so far...
2) I rewrote malloc.c (malloc, realloc, free) from scratch,
so initially I allocate 16 Mbyte (using the old malloc),
and then just return an increasing pointer to the application.
free doesn't do anything at all. I rebuilt CC1.EXE
and everything seemed to work with this approach as well.
Now I think I will test 1) for a few days and see what's happening.
Erik
- Raw text -