[Bf-committers] Re: Bf-committers Digest, Vol 16, Issue 47

[Jonathan Merritt]

Yomgui wrote:

>3. just put an "if (malloc == NULL) { handle null pointer }"
>There are not so malloc() in the code... ;-)
>You've already done much complexe things in past, no ? ;-)
>  
>

Of course - I knew I was missing something! :-) :-) :-)

The issue here is that the blocks you refer to normally look something 
like this:

z = malloc(N);
if (z == NULL) {
    /* free x */
    ...
    /* free y */
    ...
    return NULL;   /* or FALSE, or whatever */
}

The list of things to free increases as you progress through your 
mallocs().  Take a look at well-written code that uses image libraries 
(PNG is a great one) for examples of this.

The calling function then has to check for a failed return as well, and 
must proceed to unwrap and free all of its resources, before passing the 
failed result up to ITS caller,  which has to do the same thing, etc...

Now, for atomic events - things that are triggered in response to a 
direct user input and have clear-cut consequences - the desirable 
behaviour is surely to inform the user that their command could not be 
completed.  However, if a failure to allocate memory occurs in an event 
loop or somewhere else where it *should* really succeed, then unwinding 
everything and simply returning a "failure" to the caller is not always 
so simple.

As a hypothetical example (I'm not sure of the code here, so I'm just 
guessing this could happen...), imagine that a memory allocation failure 
were to occur in response to a mouse dragging a vertex of a mesh, or a 
frame-change being unable to draw the scene in the new frame.  What does 
it mean for these actions to "fail"?  Surely these are situations (or 
others very similar) where there would be no recourse but for Blender to 
quit.  In these situations, a "malloc or die" function would be 
desirable, I think.

Jonathan Merritt.