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

Jorrit Tyberghein jorrit.tyberghein at gmail.com
Fri Nov 25 10:52:52 CET 2005


>     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.

Greetings,

>
> Jonathan Merritt.
>
>
> Jorrit Tyberghein wrote:
>
> >Hmm... Exactly how is a system that is returning null for malloc a
> >f*cked up system? On my linux system I have 512Megs RAM and 1Gig swap
> >(not an uncommon setup). Assume that I still have 300Megs free (which
> >is plenty) and then something does a malloc of 300 megs which fails.
> >How is this a f*cked up system? Code should check for failure on
> >memory allocation IMHO. Now in practice I realize that few programs
> >actually do that (Crystal Space doesn't do that either) but returning
> >NULL for malloc is not always indicative of your system being messed
> >up. It can simply be that there is not sufficient memory available for
> >the allocation.
> >
> >Greetings,
> >
> >
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>


--
Project Manager of Crystal Space (http://www.crystalspace3d.org)
and CEL (http://cel.crystalspace3d.org)
Support Crystal Space. Donate at
https://sourceforge.net/donate/index.php?group_id=649


More information about the Bf-committers mailing list