John Morris writes:
> Not a problem at all. An API is a contract, violate it at your peril.

Let's see...

> The malloc() call's contract is you request memory with the
> understanding that "no" is a legal answer.

Indeed. But keep in mind what the contract actually is. NULL means there
was an error, but a problem such as lack of RAM doesn't require malloc() to
return NULL. The contract does not include isn't a bijective equivalence,
only an injective implication. In the words of the linux man page, "when
malloc() returns non-NULL there is no guarantee that the memory really is
available".

I have personally seen linux/glibc malloc return non-NULL even though there
was FAR too little RAM, and also seen it return NULL even though there was
more than enough RAM (the hardware was purchased for the software). If you
think hard enough about malloc's contract you'll understand how the latter
is possible.

> If you fail to account for
> that possibility (tactics like preallocation) you either made a mistake
> or worse, failed to understand the nature of the deal. On the other
> hand, a tactic of simply allowing the process that hits the memory
> limit to die, thus freeing up some memory, might be the winning move.
> If you can't accept that, program in a language which deals with those
> sort of low level details for you and accept the solution it chooses
> when a request for memory fails. C isn't for everyone and isn't the
> best answer to every problem.
>
> After all, wrapping malloc in a simple test for NULL and exit beats
> just assuming any malloc will succeed.

Let's assume, for the sake of argument, that this really were true. No
oom-killer, no overcommit, errors returned locally to first allocation.
What difference does if (!(a=malloc(12314)) exit(42) make compared to e.g.
the oomkiller?

The grandparent message (by Stephanie Dougherty) argued that unplanned
exits tend to have an actionable and problematic root cause. My response
argued that those also happen because of routine occurences such as a
server running near capacity combined with the simplicity of operator new,
malloc() and a few other similarly simple things.

You argue that... what? C isn't for everyone, you write. Do you mean to
suiggest that C isn't for writing servers, or C isn't suitable if one
wishes to run a rackful of servers near their maximum capacity? Or do you
suggest that when a server process quits because of if(!malloc()) exit()
that has different implications regarding restarts and reliability than if
the process is killed by the oomkiller? Or what?

Arnt