On Wed, Jan 20, 2010 at 2:43 PM, Sean McBride <span dir="ltr"><<a href="mailto:sean@rogue-research.com">sean@rogue-research.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 1/20/10 1:28 PM, David Cole said:<br>
<br>
>If anybody knows the details about contributing to zlib, point me to them.<br>
>I'd be happy to coordinate contributing this change back to them... Whether<br>
>they'll accept it or not, I don't know, but it's worth a shot.<br>
<br>
</div>Well, they say in their FAQ that they knowingly introduced this (by<br>
changing from calloc to malloc) for performance reasons. So I doubt<br>
they would change back. :( It would be interesting to know how big a<br>
performance impact this has. 1%? 1000%?<br></blockquote><div><br></div><div>Yes. And I do not change it back to calloc. I add a single memset to 0 after a single allocation that fixed the valgrind report on the CMake dashboard. I am going to wait until tomorrow and inspect the VTK and ITK valgrind results before I propose fixing it to the zlib guys...</div>
<div><br></div><div>But still: changes for "performance reasons" that introduce uninitialized memory accesses are just plain wrong. Penn & Teller would call it something slightly more colorful if they ever commented on C++ code.... I do not care how fast you can decompress my data if there's the possibility that something about it will be incorrect or that it will just plain crash. And uninitialized data always comes back to bite you in the end.</div>
<div><br></div><div>Nothing against the zlib guys, but their answer to FAQ #36 is just wrong. It *is* a bug and they should fix it.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Also, I feel compelled to point out :) that if zlib was not triplicated<br>
in CMake, VTK, and ITK that your fix from 2 months ago would have solved<br>
this once and for all. :) When and if you guys switch away from CVS, it<br>
would be good to investigate some kind of 'Shared' repository that all<br>
these projects use. IMNSHO. :)<br></blockquote><div><br></div><div>We know. I agree completely... we will see to what degree we can achieve this beyond the current kwsys and metaio sharing that we have in place already.</div>
<div><br></div><div>thx,</div><div>David</div><div><br></div></div>