On Wed, Feb 5, 2014 at 5:54 PM, Tom Hughes <t...@compton.nu> wrote: > On 05/02/14 22:49, Jeffrey Walton wrote: > >> Are you stating those are two different findings? If they are two >> different findings, shouldn't there be two different: > > > Well it's one finding, but there are two pieces of information associated > with that finding. > > The first is the location where the uninitialised data was used and the > second (which occurred at some earlier point during the program's execution) > is the location where the memory containing the uninitialised data was > allocated. > > The two are separated by the "Uninitialised value was created by..." line > which tells you that what follows is the location of the allocation. > > Because suppressions match at the point where the data is accessed they > match against the stack at that point in time. Thanks Tom.
Well, I'm not sure how to proceed since RAND_init_fips is the linchpin. A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK. A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD. I'm fairly certain I need to include RAND_init_fips to rule out a legitimate uninitialized read, but I'm not sure how to do it. Any ideas how to craft this rule? Thanks in advance. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
