|
From: Nicholas N. <nj...@cs...> - 2006-08-12 00:43:17
|
On Sat, 12 Aug 2006 dom...@fr... wrote: > Valgrind currently does not check for pointer arithmetics > or pointer comparisons on unrelated pointers. I am not > sure whether it could be possible to detect such bugs > with valgrind. > > [...] > > -> could valgrind be able to detect such bugs? I suspect this would be both difficult to do, and not that useful. First the difficulty. The hard part of this is working out what is a pointer, and what is not. It's easy to do with pointers to heap blocks, because they're returned by malloc(). Addresses of stack and static variables are much harder to find -- basically you have to rely on debug info to find them. Another difficulty is that programs often use pointer differencing that is undefined according to the C standard, but almost always works. The classic example is something like memcpy or memcmp, where you find the difference between block1 and block2, and then increment block1 one byte at a time -- you can find the corresponding byte in block two by adding the difference to block1. This works on any typical machine. There may be other examples; in my experience real programs often do far stranger things than you might expect. Using the C spec as a guide for finding bugs is questionable anyway, since Valgrind is really operating at the binary level, where programs may not be written in C. As for the usefulness, I suspect this kind of thing is not a common source of bugs. Have you ever had a bug caused by this kind of operation? You might be interested in reading "Bounds-Checking Entire Programs Without Recompiling", a paper at http://www.valgrind.org/docs/pubs.html. It talks about a tool that does bounds-checking, and covers in more detail some issues related to this idea, such as finding pointers. One basic conclusion of this paper, although the paper doesn't say it as such, is that trying to do stuff that relies on pointers via binary instrumentation is pretty difficult, and would be better done via source-level instrumentation. Nick |