https://bugs.kde.org/show_bug.cgi?id=243234 plasmahh@gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |plasmahh@gmx.net --- Comment #2 from 2010-06-30 11:50:16 --- 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? I would understand perfectly the message if this internal pointer somehow managed to derive from buf0 a ptr that is then suddenly pointing into buf1, buf if that ptr is really *set* to point to buf1 -- the parameter to sscanf -- shouldn't ptrcheck see that as not being derived from the previos buf0 pointer, but set to something from "outside"? if an implementation would do int x = param2 - param1; char* ptr = param1; /* use ptr */ ptr += x; /* use it again*/ then I would say the complaint is correct, buf if it does char* ptr = param1; /* use ptr */ char* ptr = param2; imho ptrcheck should be able to detect it. 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. 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 with our old legacy code here we find quite some bugs with ptrcheck that no other tool shows us... -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.