mimalloc: Missing C++ operators taking `std::nothrow_t`

Maybe the existing runtimes do by incident, I haven’t checked, but you’re relying on implementation detail of the runtimes.

Only some of them do that. Some of them do not. Especially when in debug builds with debug runtimes/libraries in play.

(or perhaps not bother overriding at all since they all use malloc underneath…)

This is not true. It may be true on some platforms (libstdc++ maybe) but is not true on others.

To be very clear, it is also not true to ever assume that one overload of new will ever call a different overload of new by default.

To do otherwise is to invoke undefined behavior.

If mimalloc is overriding new, I would not only absolutely expect it to override all overloads, I would also expect that with mimalloc’s debug/security/correctness layer turned on that mimalloc would detect and raise an error when new and free (or malloc and delete) are inappropriately paired, just like some existing C++ standard library implementations do today.

Just pushed a new commit that implements the correct overriding for new/delete if compiling with a C++ compiler; adds overrides for all current new/delete variants including nothrow etc. When using a C compiler we cannot call get_new_handler or throw exceptions, so in that case these are not overridden at all and we rely on the standard implementations calling malloc/free under the hood. (we do override aligned_alloc as well so everything should work now) 😃

When the standard says throw bad_alloc then the operator should do it. It is the caller who should be able to do something about it, if he wants to. Also note that there is set_new_handler API.

The implementations call the non-throw versions and those are overridden.

I haven’t found where, in mimalloc, they are overridden.

Even stronger, for overriding to work, you don’t even need to override new as that eventually invokes malloc.

First, operator new doesn’t necessarily have to call malloc. Maybe the existing runtimes do by incident, I haven’t checked, but you’re relying on implementation detail of the runtimes.

Second, if you want to rely on implementation details, then at least be consistent about it. Either override all operators, or none. At least, if the operators don’t use malloc/free, they will be able to work with whatever heap they all use.