Why does replacing malloc () require linker knowledge, but :: operator new () doesn't?

Question

See related question.

The difference between the global operator new and malloc

Accepted response conditions,

"Replacing malloc opens a can of worms. This can be done, but not portable, because this requires knowledge of the linker."

Why does malloc replacement require linker knowledge and why does :: operator new () not replace?

Answer 1

The C ++ standard provides restrictions on ::operator new . Although the implementation is certainly messy and related to linkers, a C ++ program can simply define another ::operator new , and it works. The C ++ standard explicitly states: "Programs can replace them with their own definitions (etc. Etc., Various restrictions and details).

malloc , on the other hand, is a regular function defined in a regular library, and C (and C ++, for that matter) does not have the ability to replace such a function. You can convince almost every linker under the sun to associate it with libc sans malloc and allow links to malloc to some code from another library / object file. But you cannot just define different malloc functions, since this violates one definition rule: as a result, you get two functions called "malloc", which is prohibited by the standard (for non- static , non-anonymous- namespace , non inline , ... ) and a serious problem for linkers (most likely, an error or one of the two definitions is discarded).