David Schwartz wrote: > Umm, why? > > 1) This is an unusual use case.
This is not an unusual case. I'm a developer and I valgrind my code all the time because fixing problems shown up by valgrind makes my code better. My code is targeting an embedded Linux box and I try to ensure that the system I develop and test on is as close as possible to the embedded target. Using a different version of openssl sort of defeats that aim. > 2) Zeroing memory that doesn't need to be zeroed has a performance cost. Yep, I agree, for code that doesn't give valgrind warnings. A couple of years ago I attended a very interesting presentation by Andrew Tridgel of the Samba project. He explained that they avoided zeroing memory wherever possible. However, they used valgrind and had a rigorous policy of fixing all valgrind warnings. Tridge's claim was that doing this maximized performace and guarded against information leakage onto the wire. > 3) It's very easy to recompile a debug build for debugging. But if I do that, my test system is no longer the same as my target. > IMO, the default build should always be a release build with release > optimizations and tradeoffs. A debug build should be the exception. I'm not asking for all uses of malloc to be replaced with calloc, I'm asking for the very small number of areas that produce valgrind warnings to be fixed. Since they are small in number it is unlikely that any performance decrease can even be measureed. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- The Earth is around 70% water. Fish rule the seas. Humans are over 90% water. It's only a matter of time. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
