Community
Participate
Working Groups
Assignments in conditions are slipping through in code like that: if ( (x==0) && (y=0) ) // no marker on y
This is intended. More in the case like this if ((a=b)) {...} The way to say to tool - I know what I am doing
(In reply to comment #1) > This is intended. More in the case like this > if ((a=b)) {...} > The way to say to tool - I know what I am doing I vaguely recall this discussion but now I think it is pretty obscure to a user. I think it would be better to invent a system of tags which could be specified in comments to suppress codan warnings, similar as done for switch/break checker or java @SuppressWarnings annotation. As far as this particular case, I think it is pretty common to have company policy not to allow assignments in conditions, it would be desirable to have the checker working under that policy too.
I agree. Even if if ( (a=b) ) is clear, the case in description is a good example of typical accidental assignment. Should I modify the checker to check comments before the condition statement for some key text, just like with case fallthrough?
BTW this issue was already mentioned in bug 307414. The checker assumes that an assignment in () is always intended. This assumption only works for simple conditions, I think. Some people do if ((a == 10) && (b == 20)) and put the extra parentheses because they are unsure about operator priorities or they just think it looks better. It's a matter of code style and the checker shouldn't ignore = instead of == here. I'd suggest to drop using parentheses here and just use a comment tag like "no break" in case fallthrough- much more clear and won't cause problems.
For static analysis it is better to have false negatives than false positives, assignment in conditions are quite typical is C if ((k=read())!=-1) { ... } What we can do if to add a parameter to a checker, which is not on by default [ ] Report all assignment in conditions, even in brackets (Or one that is on by default [*] Do not report assignments in brackets ) Adding suppressing comments is a good anyway, I am working (very slowly) on adding a framework to use it in all checkers.
(In reply to comment #5) > Adding suppressing comments is a good anyway, I am working (very slowly) > on adding a framework to use it in all checkers. How is that coming along?
