Re: standard error handling for malloc() broken for user root and group wheel

Poul-Henning Kamp wrote:
> In message <4034700C.9090107_at_kientzle.com>, Tim Kientzle writes:
> 
>>Aborting the program
>>on a failure to allocate memory is pretty clearly a violation
>>of the standard, which requires the malloc function to
>>always return.
> 
> There is neither requirements nor guarantees how any function in
> the ansi/iso regime reacts if you grossly violate the API or stomp
> on random memory.

If malloc's internal data structures are corrupted, I
completely agree that a prompt abort is appropriate.

My concern is that the current 'A' flag aborts on a failure
to allocate, which is not a "gross violation" of the API.
(I can see where it would be a useful debugging crutch, but it
should not be enabled by default for any production code.)

For example, consider a program with a dynamically-sized cache;
a failure to grow the cache is not a reason to abort
the program.  Even for programs where an allocation failure
is fatal, well-written programs can and do handle this
failure gracefully and give the user useful feeedback.

> -
> -    if (malloc_abort && result == NULL)
> -	wrterror("allocation failed\n");

Removing the abort on a failed allocation would
address my concerns with the current behavior.

Tim Kientzle