[Bf-committers] Re: [Bf-blender-cvs] CVS commit:
branan at gmail.com
Fri Oct 27 22:11:13 CEST 2006
if a check for NULL is added to the malloc wrapper, it covers everything.
>From there, the decision is how to handle that fail. A generic bail
function is a possibility, for sure. Another thing (which I don't
intend to write, I'm just making a suggestion) is to add some sort of
"virtual memory" to blender... That would involve re-writing the
library system, to use some sort of unique key, instead of memory
addresses... A lot of work, but it allows for up to 4 billion library
items (on a 32-bit machine), even though RAM is much smaller. This
would also get rid of the need for the multi-process hack on MacOS (is
that hack stillin Blender?)
On 10/27/06, Martin Poirier <theeth at yahoo.com> wrote:
> --- Alexander Ewering <blender at instinctive.de> wrote:
> > Apart from being redundant, why would anyone ever
> > pass NULL to a function
> > that is supposed to do something with the argument?
> > It would be the task of
> > the calling function to make sure that it doesn't
> > pass NULL.
> Or rather, use ASSERT(foo != NULL), so it can be
> tested when debugging but doesn't affect releases.
> That is, assuming receiving NULL as parameter has no
> meaning, in which case, it's much better to trace it
> than to ignore it.
> > This slightly thoughtless "do everything so that
> > code analysis tool foo / bar
> > is quiet" probably more increases noise in the code
> > than what it's worth.
> I disagree, while simply bailing out on NULL might not
> be the optimal solution, it's much better then
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> Bf-committers mailing list
> Bf-committers at projects.blender.org
More information about the Bf-committers