Quoting "Dallman, John" <[email protected]>: >> However it is possible to pack the structs without holes... > > You will not like what this does to performance. It also means > that you will be Valgrinding a different build of your software > from the one that gets run in anger.
I understand the performance penalty. I also understand the binaries will not be exactly the same obviously. But, isnt it so that when we run a program with valgrind, it is already not the same as running it without valgrind in a similar sense? Valgrind changes the program execution, am I wrong? But, lets say slowness and using a different build of the software are acceptable risks for finding uninitialized values under certain cases where it is very difficult to manually track uninitialized values. I would gladly compile the software so structs will be without holes just to find uninitialized values easier. Perhaps, after that, I can compile to software normally again for other purposes. The real question is if the structs being padded by the compiler the only reason why there cant be uninitialized value checks or are there other reasons? In other words, if this compiler option was used, would it be possible for valgrind to do eager checking of uninitialized values without false positives? Thanks, Evren ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
