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 <[email protected]> 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 [email protected] www.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
