5 ms·
> blame UNIX for that, and the fork() system call. Given that most code I have seen would not be able to handle an allocation failure gracefully I wouldn't cal
by josefx 4y ago
> blame UNIX for that, and the fork() system call.
Given that most code I have seen would not be able to handle an allocation failure gracefully I wouldn't call it "blame", if the OS just silently failed memory allocations on whatever program tried to allocate next you would basically end up with a system where random applications crash, which is similar to what the OOM killer does, just with no attempt to be smart about it. Even better, it is outright impossible to gracefully handle allocation failures in some languages, see for example variable length arrays in C.
- tjoff 4y agoThat 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.
- josefx 4y ago> 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-malloc/ 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.
- tjoff 4y agoVLAs 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.
- Arnavion 4y agoNo 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.
- kevin_thibedeau 4y agoPlenty of code runs on systems without that behavior. Graceful handling of malloc failure is still useful.
- Arnavion 4y agoI know. I myself write code that checks the result of malloc. I was responding with josefx's words.