|
From: Christoph B. <bar...@or...> - 2007-10-16 14:43:54
|
Am Dienstag, 16. Oktober 2007 schrieb Robert Cussons: > Ok, this is not really like the original thing I had in mind, and I have > found that a number of the other places that I thought were complaints > about my code actually referred to places in included libraries. > > ==9866== Conditional jump or move depends on uninitialised value(s) > ==9866== at 0x401E66C: rawmemchr (mc_replace_strmem.c:547) > ==9866== by 0x4098E61: (within /lib/tls/i686/cmov/libc-2.3.6.so) > ==9866== by 0x408DBDC: vsscanf (in /lib/tls/i686/cmov/libc-2.3.6.so) > ==9866== by 0x40890AD: sscanf (in /lib/tls/i686/cmov/libc-2.3.6.so) > ==9866== by 0x804864D: main (in /the/cussons/testvalgrind/test4) There is no line number shown for main. This indicates that you did not compile with debug symbols. Use -g for memcheck. > I was reading errors like the above to mean that there is a conditional > in main that is dependent on an uninitialised value, which I knew but > thought the problem should be resolved by the value being set during the > function, however the above error can also mean that somewhere in the > rawmemchr function there is a variable used that is uninitialised and > just because I happen to call that function, I get the warning, is that > correct? Now I see the big thing with suppression :-) You are right. The error might happen along the whole path from main to rawmemchr. But you should assume that sscanf and the functions it calls work correctly, if you do not implement them right now. > I have attached the below just in case anyone is interested, the output > I get from valgrind is given at the bottom. I guess that the point here > is that if we satsify the if condition then the variables: typename, > gamma, kappa and label aren't initialised, because the values aren't > there to initialise them to, of course valgrind doesn't know that I > don't care about this eventuality as if it happens the program is going > to exit straight away. To avoid this complaint I suppose I would have to > loop over all the elements in each array giving them an initial value, > or is there an easier way to get valgrind to accept them as initialised? No. Your program is not correct. The array buf is filled with garbage values that are not initialized. The sscanf() call tries to interpret the garbage and this results in the valgrind messages below. The correct approach here is to fill the buffer with a string that sscanf can interpret. Greetings Christoph |