Re: When to check the return value of malloc

"Malcolm McLean" <regniztar@xxxxxxxxxxxxxx> writes:
"Keith Thompson" <kst-u@xxxxxxx> wrote in message
"Malcolm McLean" <regniztar@xxxxxxxxxxxxxx> writes:

How difficult is it to compute the probability that a single call to
malloc() will fail? How difficult is it to check the result? What
are the "maintenance costs" of ensuring that your probability
estimates remain correct as the program evolves? Compare and
contrast.

Just check the result of every single call to malloc(). If you can't
think of a more sensible way to handle failure, just abort the
program. Use a wrapper if you like; call it "malloc_or_die()". There
is no excuse for not checking the result of malloc(), except *maybe*
in a quick throwaway program.

(Please note that I'm not generally advocating aborting the program on
a malloc() failure; I'm just saying that it's better than ignoring
it.)

Typically something between 33% to 50% of code will be there to handle
malloc() failures, in constructor-like C functions. If malloc() fails
they destroy the partially-constructed object and return null to
caller. Typically caller has to simply terminate, or destroy itself
and return null to a higher level, which terminates.

So xmalloc() is a worthwhile simplifier. But it is not a good strategy
for dealing with out of memory conditions. It's simply the best
strategy that I can think of that can be implemented in conforming
C. When the error-handling code is called only once in a trillion
years or so of operation, obviously we are not too bothered about
ideal operation. Howevewr you cannot be expected to do this
calaculation all the time. The heuristic is "is this aloocation likely
to be large enough to have a realistic chance of failure?" If the
answer is yes, call malloc(), check the result, and treat null as one
o fthe normal execution paths of the program. Otherwise call
xmalloc(), and just tolerate the sub-optimal processing.

But that's not what you wrote upthread. What you wrote was:

[...]
The chance of the computer breaking during this period is so so
much higher, there is in this case no point checking the malloc().

You seemd to be talking about calling malloc() and blindly assuming
that it succeeded, not about using xmalloc() to abort the program if
malloc() fails.

Perhaps that's not really what you meant.

--
Keith Thompson (The_Other_Keith) <kst-u@xxxxxxx>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: xmalloc string functions
    ... returns NULL on failure. ... g_malloc() is not a raw wrapper around malloc. ... and do stuff where mallocfails. ... reporting an out of resources message a lot more often than it crashes ...
    (comp.lang.c)
  • Re: When to check the return value of malloc
    ... Avoiding checks on the basis that "probability of failure is low ... Two situations where you can go without checking for malloc failures: ... If you can calculate the maximum amount of memory used ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... There is nothing to recover because failure of fopen ... of malloc() when you are trying to allocate a structure ... then you can safely abortwhen fopenfails. ... doesn't have memory to draw stuff it draws. ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... If fopenfails, there is nothing ... to recover from. ... than a NULL return from malloc(). ... pointer value to null at the point I want to trigger the failure. ...
    (comp.lang.c)
  • Re: When to check the return value of malloc
    ... that the probability of failure is sufficiently low. ... assume malloc succeeded. ...
    (comp.lang.c)