I'm expecting a link error because it'll conflict with the existing standard implementation.
Your expectation is incorrect: most UNIX libc implementations support using some other malloc. To that end, they put malloc
, realloc
, free
etc. either into a separate object file, or each into an object file of its own.
The linker is then free to replace malloc.o
in libc.a
with your implementation. You can read about the algorithm the linker uses here. Once you understand the algorithm, it should be clear why linking your own malloc
and free
does not cause a link error.
UNIX shared libraries are explicitly designed to emulate archive libraries, so while details of why you don't get a link error when linking with libc.so
are different, the spirit is the same.
However, you aren't done. Linking any moderately complicated program with your implementation will likely crash, because when you replace malloc
, you also need to implement realloc
, and likely calloc
and memalign
and posix_memalign
. Otherwise, you'll get a mixture of implementations, and when someone passes realloc
ed pointer to your free
, things will likely explode.