3 ms·
> For instance, I generally abort() on NULL after printing a message. Ok, but...how are you printing the message? On many platforms, with many standard librar
by msbarnett 8y ago
> For instance, I generally abort() on NULL after printing a message.
Ok, but...how are you printing the message?
On many platforms, with many standard libraries (glibc, for instance), printf et al will themselves malloc memory, so you're testing for a system telling you it couldn't allocate memory and then in response, potentially triggering further quite-likely-failing allocations that may or may not be handled by the library.
This is why people generally don't bother to check for NULL mallocs. Even if you're on a system that will even tell you you're in that situation (rare, these days, outside of the embedded world), there's almost nothing useful you can do.
- convivialdingo 8y agoYou’re absolutely correct, in this manner of development you just hit a wall and call it a day. A few years back I read quite a few papers on NASA’s development standards and did quite a bit of kernel dev also. I no longer do any allocations on daemonized or driver code like this. It’s far better to preallocate pools, store temp objects on stack and generally never malloc outside of the pool management. When we hit the alloc wall, we now have well-defined behaviors and can gracefully choose whether to reject, clean or error out. Additionally our code is generally more performant, less buggy, and easier to debug.
- loxias 8y agoYou're absolutely correct. (full stop) Honestly, in my own code I try to avoid lots of little heap allocations (duh), and when writing embedded things I don't have printf or malloc anyway.