> 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. I didn't say it was an unusual use case for you. It's an unusual use case for OpenSSL. > 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. Then you have to make a tradeoff. You can either debug in a release build and suffer the added complexity or you can release a debug build and suffer the performance loss. But others don't have to make that tradeoff, and there's no reason your problem should force them to. > > 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. He's absolutely right. Here, Tridge's argument works the other way. We *want* as much information as possible to "leak" into the PRNG. > > 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. Then you are welcome to ship a debug build with your target. That's your tradeoff to make. The vast majority of people don't have such a tradeoff, so it's kind of silly that they should suffer its costs just because you have to. > > 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. Then you are welcome to compile with -DPURIFY even in your release build. That does exactly what you ask for. I've already explained why that's not the default -- your case is unusual and so it should *not* be the default. A single extra flag is an extremely minimal cost. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
