|
From: Ashley P. <as...@qu...> - 2007-03-12 12:18:39
|
On Sat, 2007-03-10 at 12:24 +0000, Julian Seward wrote: > [Marginally OT ..] I wouldn't have said so. > Perhaps a better fix is to set those V bits to 'undefined' in that case. > > iow, for a read which partially overlaps the end of a block: > > - With --partial-loads-ok=no [the default] > give an addressing error, and set the corresponding V bits to 'defined' > > - With --partial-loads-ok=yes > do not give an addressing error, and set the corresponding V bits > to 'undefined', so we yelp later if anybody uses them > > If this sounds all a bit arcane, that's because it is :-) The last part > of Sec 2.7 of http://www.valgrind.org/docs/memcheck2005.pdf might help. I had to read that two or three times to understand it but yes I think you are right, it's probably "OK" to set the Vbits to defined if a error was raised when they were read but if the error was suppressed then they should be set to undefined. This highlights the sensible but not always obvious approach that when diagnosing programs with memcheck errors the errors should be tackled in chronological order rather than in order of severity, in particular earlier "invalid read" errors could have the effect of hiding later "undefined behaviour" errors. Ashley, |