Oh wow, I guess there is no way to use "with all due respect", without sounding really pissed ;-)
Didn't mean to sound angry. On the topic of casting the return of malloc... The same can be said for function pointers passed as callbacks. There is no need to pass in a void and cast it to a function pointer in C code. You can just have the parameter be the correct type and it will work fine with no warnings. Not advocating that this be done right away, but I did make this cleanup in some of the drawing code in swiss-cheese. On Tue, Jan 29, 2013 at 6:18 PM, Jason Wilkins <[email protected]> wrote: > With all due respect, I did not miss the point. Stephan Swaney got > what I meant. > > What frustrates me is my mistake is lumped in with this. I did not > make my change solely because I thought the code was ugly. I did it > because the code was out of sync with my branch and I missed a bugfix > because of it. I screwed up and reintroduced the bug, but that > doesn't have anything to do with "code cleanup". I thought the change > was more readable, so that is what I put in the change log. > > Anyway, I'm over it now. The change will be made once the > compatibility stuff gets merged. I just lost a chance to remove a > minor merge headache. > > The compatibility code is full of these kinds of cleanups. That is > why I'm testing the hell out of it. > > On Sun, Jan 27, 2013 at 3:29 AM, Ton Roosendaal <[email protected]> wrote: >> Hi, >> >> You miss the point Jason. It's not about being stupid or not thinking enough. >> It shouldn't even have come up in a coders mind to "fix" it. >> >> -Ton- >> >> ------------------------------------------------------------------------ >> Ton Roosendaal Blender Foundation [email protected] www.blender.org >> Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands >> >> On 26 Jan, 2013, at 22:02, Jason Wilkins wrote: >> >>> 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 >> >> _______________________________________________ >> 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
