3 ms·

> Checking the return of malloc() for NULL is not currently considered good practice Why? To quote malloc(3): On error, these functions return NULL. NULL

by loxias 8y ago

> Checking the return of malloc() for NULL is not currently considered good practice Why? To quote malloc(3): On error, these functions return NULL. NULL may also be returned by a successful call to malloc() with a size of zero, or by a successful call to calloc() with nmemb or size equal to zero. I'm not disagreeing with your assertion that on linux, in practice, it doesn't return NULL -- (in fact, I didn't know that! and would appreciate being pointed at whatever I need to RTFM...) -- I just prefer code that's conservative, that follows the "letter of the law" when it comes to return values.

kazinator 8y ago
If you write code that tests for null out of malloc, you have to commit to that code as a feature and have a test strategy for it. Simply porting the program to a platform where malloc returns null isn't enough; there are various cases to probe, like your very first malloc failing because the program was started in a low-memory environment. Or the case that the 99th malloc fails after 98 good ones.
- loxias 8y ago
  Oh, I'm not saying you should test for NULL and then, uh, not care about the result! If you port to some new platform, of course you need to go back and check the docs for new error codes. For instance, I generally abort() on NULL after printing a message.
  - 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 ago
      You’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 ago
      You'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.
  - kazinator 8y ago
    "care about the result" means: - come up with a requirement about handling the bad result - put in the code which does it - test the code > I generally abort() on NULL after printing a message. On most modern systems, accessing the null pointer will also abort; you just won't get the nice error message. It will look the same as if the program hit a runaway recursion, or corrupt memory. The location in the program where it happened is equally traceable either way (with a core dump or debugger). Neither a segfault nor abort() do any graceful cleanup of anything. Basically, this is only a tiny increment in software quality over not handling the NULL at all.

by loxias 8y ago

kazinator 8y ago

If you write code that tests for null out of malloc, you have to commit to that code as a feature and have a test strategy for it. Simply porting the program to a platform where malloc returns null isn't enough; there are various cases to probe, like your very first malloc failing because the program was started in a low-memory environment. Or the case that the 99th malloc fails after 98 good ones.

loxias 8y ago
Oh, I'm not saying you should test for NULL and then, uh, not care about the result! If you port to some new platform, of course you need to go back and check the docs for new error codes. For instance, I generally abort() on NULL after printing a message.
- 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 ago
    You’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 ago
    You'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.
- kazinator 8y ago
  "care about the result" means: - come up with a requirement about handling the bad result - put in the code which does it - test the code > I generally abort() on NULL after printing a message. On most modern systems, accessing the null pointer will also abort; you just won't get the nice error message. It will look the same as if the program hit a runaway recursion, or corrupt memory. The location in the program where it happened is equally traceable either way (with a core dump or debugger). Neither a segfault nor abort() do any graceful cleanup of anything. Basically, this is only a tiny increment in software quality over not handling the NULL at all.