> Valgrind runs on unmodified binaries - and it's not always > possible to get someone else to recompile their code so that > you can find problems. OpenSSL is used in commercial products > where source isn't always available.
Valgrind *can* run on unmodified binaries, but when you do that, you get lots of false positives and false negatives. In most realistic scenarios, OpenSSL is far from the least of your problems trying to do this, and it's unlikely you'd be able to make any sense of the output if you didn't have the source code. > Since there's no performance impact from fixing this, and > the concensus is that there's no security gain from leaving > the code as is I simply don't see the point of not changing this. There is a performance impact for this change. That's why the general philosophy is to make optimizations that confuse memory tracking programs in release builds and to disable them in debug builds or builds specifically for memory tracking. > "very few people see it" is true of most bugs :), but it's still > not a good reason to avoid fixing problems. This is neither a problem nor a bug. It's an optimization that valgrind can't cope with. To remove the optimization just for people using valgrind is a bad tradeoff. There are a long list of things you can't do in valgrind builds and avoiding all of them just in case someone is going to run valgrind on a build for which they have no source code and likely can do nothing with the results is a bad tradeoff. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
