[Bf-committers] Some words about a strange thing named

[Jonathan Merritt]

Jorrit Tyberghein wrote:

>>    3. (...)?
>>These things should surely be implemented in a high-level memory
>>manager, not peppered throughout the code in every function that
>>allocates memory.  Does anyone disagree?
>>    
>>
>
>Well how would you do that? i.e. imagine code like this:
>
>char* a = malloc (1000000);
>*a = 1;
>
>How exactly would you ensure that Blender doesn't crash while trying
>to do *a = 1 if there is not sufficient memory? 'malloc' has no choice
>but to return NULL. So I don't think you can avoid checking for NULL
>unless you use C++ and exceptions but that's probably not an option
>here.
>  
>

Fair point! :-)  A: by not using malloc() directly. :-)

Blender's MEM_mallocN() function goes some way toward what I'm 
suggesting.  What it could do is have an extra flag which means "and try 
*REALLY* hard"!  If that flag is set, the function should try to exit 
the program cleanly if memory allocation doesn't succeed.  Otherwise, 
it's up to the caller to check the return value.

What I'm getting at is that in many cases, running out of memory is 
surely a pathological event (the reason, as you point out, why 
out-of-memory is normally an exception in higher-level languages).  
Since we can't use exceptions, maybe we can implement part of that type 
of functionality in a malloc wrapper instead of dealing with it in detail?

Jonathan Merritt.