https://bugs.kde.org/show_bug.cgi?id=243234 --- Comment #4 from Julian Seward 2010-06-30 12:29:41 --- (In reply to comment #2) > I have not really looked at the sscanf implementation (and my doctor says I > should not as it won't be good for my heart), but if the pointer jumps from one > arg to the other, shouldn't ptrcheck somehow get that it has been > re-initialized from a new input parameter then? The problem is .. The basic assumption is: if a memory referencing insn accesses a stack or global array, then it will continue to access that same array until the containing stack frame exits. See http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.how-works.sg-checks So .. how, in this case, can it know that the insn which copies data into %s destinations is switching between destination arrays? I don't see a way to do this. > Now that I think of it, the almost 100 suppressions that I wrote for our > software seem to be of a similar kind. We have a ptr variable that is always > re-used for pointing to an element determine within the looping. Yes. See bullet point 5 of http://www.valgrind.org/docs/manual/pc-manual.html#pc-manual.limitations > It would really be nice if there could be a fix for this since it is a really > tedious thing to always write suppressions, since for every new case you have > to determine whether it is not maybe a bug, and Maybe it could be improved with better heuristics, but I couldn't think of any during development. If you have any ideas ... > with our old legacy code here > we find quite some bugs with ptrcheck that no other tool shows us... Wow. This is the first time I heard that Ptrcheck finds real bugs. That's great. Are these from the stack/global array checking only? I have (uncommitted) a cut-down version which just does stack/global checks, and omits the heap checks, since Memcheck does those faster. In fact, looking at the stack/global array checking code, I think I did a pretty stupid implementation. It could be redone to be much faster, but until now I never put much effort into improving it because I assumed the tool as a whole is not very useful (didn't find many bugs in the testing I did.) -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.