Adriaan van Os wrote:
... snip ...
This only leaves the Mac OS X malloc bug, I will do some more malloc tests and report the results to Apple.
I have no idea what the OS X malloc bug is, but I have a malloc system available that only relies on the availability of the sbrk call to function, and assumes byte addressability. I believe it to be highly portable to unices. To inject into something I simply link it before the standard library. You can also have a herd of malloc system debugging abilities. Compiles with gcc, and uses gcc varargs macros. To try it out:
http://cbfalconer.home.att.net/download/nmalloc.zip
(It specifically rejects a malloc request of about 2 Gb up)
I built it because the existing DJGPP malloc makes free and realloc O(N) operations where N is the number of free blocks. This in turn makes freeing a large group of blocks O(N*N). nmalloc changes O(N) to O(1) and ON*N) to O(N). The original became impossible in the 50 to 100k free blocks area. VC6 and LCC-Win32 have the same fault. It also reduces memory movement in realloc. I have had no problems over the past year with it, and a few others have been using it. We hope to get it into the next alpha of DJGPP 2.04.