Yes, it's desirable that that data is "unknown" however there is a
compromise possible:
Complement the area. It'll mean valgrind will only complain at the correct
place, or possibly not at all, and it's still random. The performance hit
from doing that will be so small it won't matter.
This annoyed me as well - the big advantage of valgrind is that it doesn't
require recompilation to work and it's really good if you don't have to
wade through all the flase alarms before you can find the real problems.
Peter
"Stefan Neis"
<[EMAIL PROTECTED]
line.de> To
Sent by: openssl-dev@openssl.org
owner-openssl-dev cc
@openssl.org
Subject
Re: [patch] Valgrind complaining
02/03/07 07:53 PM about unitialized data
Please respond to
openssl-dev
Hi,
> I'd also like to speak up on behalf of the **vast** majority.
>
> They don't want unnecessary zeroing of memory in frequently executed
> code paths (for which the only reason is to satisfy an infrequently
> executed testing environment that valgrind provides). Those wanting
> to run valgrind WITH OpenSSL -DPURIFY is provided.
Maybe more importantly (at least from my POV), if you're looking for
"random bytes", using uninitialized memory (assuming the OS or C
runtime doesn't initialize it anyway) instead of something always
initialized to the same fixed sequence of bytes actually might be a good
idea - or did I misunderstand something?
Regards,
Stefan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
