[badsectoracula]

I didn't notice that, but TBH is this a realistic concern? Is there an actual platform nowadays where realloc (and malloc, for that matter) ever fails, at least outside (small) embedded environments? I've being using realloc for decades and the only time i had to worry about it failing was in DOS.

Nowadays it feels like worrying about realloc failing is similar to worrying about fclose failing.

[1718627440]

It is still mandated by the standard, so absence of checking can lead the compiler to conclude UB and optimize stuff away.

Also it is commonly made to return NULL for testing.

[badsectoracula]

> It is still mandated by the standard, so absence of checking can lead the compiler to conclude UB and optimize stuff away.

The compiler can only prove that malloc/realloc may return NULL, not that it will or it will not return NULL - it is impossible for a compiler to know that as that is runtime behavior. So the most the compiler can do is remove checks for NULL in case subsequent code is written with the assumption that the pointer is valid (i.e. you use `malloc`, then try to use the pointer it returned, then you try to check if it is valid - the compiler may decide to remove that last because your earlier use assumed the pointer is valid).

> Also it is commonly made to return NULL for testing.

This is done explicitly by the developer though, it is not "normal" behavior, so the developer is opting in to that (and as i wrote earlier, testing for that case doesn't seem to be practical nowadays unless you target some limited environment).