That is a very weak argument.

Also, why would you bother to handle it gracefully when the OS won't allow you to do it?

Also, outright impossible in some languages? Just don't use VLAs if then? "Problem" solved.

> Also, why would you bother to handle it gracefully when the OS won't allow you to do it?

There are many situations where you can get an allocation failure even with over provisioning enabled.

> Just don't use VLAs if then? "Problem" solved.

Yes, just don't use that language feature that is visually identical to a normal array. Then make sure that your standard library implementation doesn't have random malloc calls hidden in functions that cannot communicate an error and abort instead https://www.thingsquare.com/blog/articles/rand-may-call-mall.... Then ensure that your dependencies follow the same standards of handling allocation failures ... .

I concede that it might be possible, but you are working against an ecosystem that is actively trying to sabotage you.

VLAs are barely used and frowned upon by most. It is not relevant enough to discuss.

Yes, mallocs in standard library is a problem. But this is rather the result of a mindset where over provision exist than anything else.

No code is written to handle allocation failure because it knows that it's running on an OS with overcommit where handling allocation failure is impossible. Overcommit means that you encounter the problem not when you call `malloc()` but when you do `*pointer = value;`, which is impossible to handle.

Plenty of code runs on systems without that behavior. Graceful handling of malloc failure is still useful.

I know. I myself write code that checks the result of malloc. I was responding with josefx's words.