[Bf-committers] Code cleanup woes

Jason Wilkins jason.a.wilkins at gmail.com
Sat Jan 26 22:02:17 CET 2013

I think this would not have broken if MEM_reallocN was exactly like
the standard library realloc.  The slight differences probably mislead
whoever was making this change.

On Sat, Jan 26, 2013 at 6:42 AM, Ton Roosendaal <ton at blender.org> wrote:
> Hi all,
> Here's another nice illustration of code cleanup that caused bugs;
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=54058
> The idea of "replace calloc + memcpy with recalloc" sounds nice, but it breaks the case when memcpy is of length zero. (zero hairs, use 'add' brush in particle mode).
> May I quote Joelonsoftware here?
> "Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby!"
> Great fun read:
> http://www.joelonsoftware.com/articles/fog0000000069.html
> Of course we should never be afraid to recode parts of Blender, but it shouldn't be with the naive assumption that the old bad messy code wasn't functional. New code should be totally and undeniably better, for users. Not for coders. :)
> We can moan and complain about our current bad particle code a lot, but it has offered a lot of good for Blender for many years. The challenge is not to make a new system with clean design, but to make a new system that's far superior.
> -Ton-
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list