disable new/delete overrides when building as C code
apparently, even if MI_USE_CXX is OFF, mimalloc still provides mangled definitions of new/delete operators. It causes inability to statically link mimaloc in our scenario, since we want to have our own overrides of new/delete functions.
Uh, but wouldn't this change disable C++ new/delete overrides entirely when not compiling as C++?
The way MI_USE_CXX is described, and the fact that there are explicitly mangled symbols, suggests that "compiles as pure C, but provides C++ overrides" is a quite deliberately chosen scenario, and that those overrides are not supposed to be available only when MI_USE_CXX is enabled.
For one, I believe that, usually, C malloc/free and C++ new/delete are backed by the same allocator; so doing the same for overrides is probably the safe options.
And secondly, but more importantly, simply disabling the code when MI_USE_CXX is off will break any users that rely on the "built with C, overrides C++" behavior.
In other words: disabling the C++ overrides probably warrants a separate build option/preprocessor macro to check.
Uh, but wouldn't this change disable C++ new/delete overrides entirely when not compiling as C++?
Yes. But it was my anticipation from an option called MI_USE_CXX being set to OFF.
Why would we ever want to override global new/delete in C only code? It's C-only code, so those new/delete are not from C standard library.
Bit tricky... if you don't want to override malloc/free/new/delete it is best to cmake with -DMI_OVERRIDE=OFF . However, this means there is no override for all those. There is no way to turn off just new/delete overriding.. Maybe we should have that but it is a bit dangerous to do this as most code assumes all are backed by the same allocator.
when exist projects redefine new/delete and static link, current config would result in multiple definition link error. I encountered this issue when compiling spec2006. a pure C override is necessary. Add a option to control this is a choice as @res2k mentioned.