microsoft
missing errno assigns
chimera linux has a patch for some missing errno assigns: https://github.com/chimera-linux/cports/blob/187f77f7f29304f886648522d36f66a1a3514409/main/musl/patches/mimalloc-errno.patch
that was needed to fix cases of e.g. allocating some huge amount of memory (like 1tb when host has 16gb) where the allocation fails, and a null pointer is returned, but the corresponding errno is not set to enomem so the application doesn't handle it since it expects it to be set (per the malloc api). perhaps this fix should be applied here too?
Hm, I'd like to point out that it may also be weird when a non-standard-library function messes with errno.
Ie, some mi_heap_ (or just mi_) function setting it? Perhaps unexpected.
Overriding malloc? That should probably set errno.
plenty of non-stdlib libs set errno on failure though. it's not weird when the interface is documented as such (and those libs do that).
and yeah, this is just about the overriding malloc case (where the malloc(3) api says that errno 'can' be set to ENOMEM for this issue. technically not setting it is conforming, but things do expect it..)
if it's more convenient to keep the current behaviour for non-malloc-shim mimalloc, then that's fine of course
I agree with @res2k - if mimalloc serves as the "global" memory manager (through overrides, interpose, or windows redirection) - then it's fair to have it set errno, but otherwise not. That's probably tricky as some kind of bool flag must be propagated up front the API part to the bottom what was the intention - e.g. calling malloc (which they may internally call mi_heap_ should set the errno, but calling directly mi_heap_ as - @res2k pointed out) should not.
Wonder if adding an option, and then defaulting based on case by case might be another solution? TBH I don't know... Because really both viewpoints are valid, it just depends on the context.
