Yes but:
If you use Purify you have to recompile anyway to instrument the code.
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.
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.
"very few people see it" is true of most bugs :), but it's still not a
good reason to avoid fixing problems.
Peter
"David Schwartz" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/03/2007 09:21 AM
Please respond to
openssl-dev
To
<openssl-dev@openssl.org>
cc
Subject
RE: [patch] Valgrind complaining about unitialized data
> > Oi. Don't do that.
> Why not?
Because it's a pure pessimization whose sole purpose is
to suppress a bogus
warnings that very, very few people even see, when there's already a way
to
suppress those warnings that doesn't impose costs on people who don't care
about them because they'll never even see them.
A lot of applications require you to compile with
'-DPURIFY' in order to
get reliable results from Purify-like programs. Intentional use of
initialized data is just one reason. Other common ones include code to
delay
freeing data in case it will be be re-allocated shortly or customized
memory
allocators which need to be disabled in order to accurate detect access to
freed memory areas.
Compiling with '-DPURIFY' is the ideal tradeoff. Always
disabling these
improvements just to make Purify-like tools is just wrong.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
