While running the binary-trees benchmark I found that the classic lib's malloc implementation was much faster than the new c lib's. That's strange because the new c lib's malloc implementation should be pretty fast.

So I wrote a test program malloc_test.c to get to the bottom of things. This test program performs 20000 malloc/free operations with varying size allocations so that the heap should be sufficiently fragmented to test edge cases.

What I found is that the classic lib's implementation has many errors, to the point that eventually memory corrupts and the test program crashes. The new c lib has 2 errors in an sdcc compile and 1 error in an sccz80 compile. Both compiles get the same random number sequence generated so the discrepancy must be down to compiler error in one or the other. I'm hoping that's all it is rather than a tiny bug in the malloc implementation itself.

To compile for the classic lib, comment out the include of stropts, the ioctl() and the pragma (classic pragma selection for %u isn't working btw).

zcc +zx -vn -O3 malloc_test.c -o malloc_test -lndos -lmalloc -pragma-define:USING_amalloc -create-app -DPRINTF
zcc +zx -vn -compiler=sdcc malloc_test.c -o malloc_test -lndos -lmalloc -pragma-define:USING_amalloc -create-app -DPRINTF

The new c lib compile line can be found at the top of the .c file.

Turn your spectrum emulator up to maximum speed to get the test over with in a few minutes.

This is rather surprising as these malloc implementations have been in use a long time in released programs without seeming to have any bugs.