Re: You don't check for malloc failure

2011/5/7 Maarten Bezemer <[email protected]>:
> Hi,
>
>> On Fri, 2011-04-29 at 09:05 +0200, Peter J. Philipp wrote:
>>> You don't check for malloc failure.  I've made a patch that is possibly
>>> wrong but it saves the program from SIGSEGV and replaces it with SIGABRT.
>
> On Fri, 29 Apr 2011, Philipp Schafft wrote:
>> But I have a question:
>> Not all of them (only had a brief look at the patch) look to be in a
>> 'safe' startup/shutdown state but code wich is run within the normal
>> operation. Wouldn't it be better to handle those cases in a diffrent way
>> because abort() will kill the process? Currently if it derefences NULL
>> the kernel will kill the process (very likely). This patch would improve
>> the situation because the behavor will be more defined wich is a big pro
>> already.
>
> Most implementations of malloc() don't return NULL except for very obvious
> cases of bad programming.
> When memory is running out, malloc() may return a valid pointer, but
> writing anything in the malloc-ed data region can still result in the
> kernel killing the process.

Hmm.. So what am I not reading right in this:
"If successful, calloc(), malloc(), realloc(), reallocf(), and
valloc() functions return a pointer to allocated memory.  If there is
an error, they return a NULL pointer and set errno"

Running out of memory is not considered as an error when calling malloc?

Romain