Micah N Gorrell <[email protected]> writes: > Doesn't `definedness' propagate in valgrind? Further, as I remember > > you would only see an issue when the uninitialized value directed a > > computation, or was output. > > > > For example: > > > > 1 int m(int x) { > > 2 return x + 42; > > 3 } > > 4 int main() { > > 5 int y; > > 6 int z = 19; > > 7 z = m(y); > > 8 if(z > 50) { > > 9 puts("big z!"); > > 10 } > > 11 return 0; > > 12 } > > > > As I remember, valgrind would complain about line 8 here, *not* line 7. > > (Please somebody correct me if I'm wrong! :) > > > > That said, is it possible that one of your arguments to SSL_read is > > uninitialized? If you throw a printf on those args on the line before > > the call, does valgrind complain at the printf? > > > > -tom > > > > That is a REALLY useful example. I've been having a bit of hard > time with th e way valgrind reports uninitialized variables, since > it isn't complaining abou t them being passed around. It is very > different from what a compiler would wa rn about for example.
Glad it helped. You might find the --track-origins=yes option useful. After I sent that mail, I actually tried it on the above program [1], and valgrind was able to tell me that the unitialized value was sourced from the stack variable `y'. The option exists in 3.4.0. Best, -tom [1] -ish. I actually forgot an include in the above, of course. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
