I have banged my head over this one for quite a while. I think it either is a false positive ... or the construct is too complex for static analysis.
Have a look at the attached report. Keep an eye on variable "expr->r->nodetype". Between points 2 and 7, it never is written. However, the analyzer assumes in step 3 that it's value is 'A' but in step 6 it assumes it has changed to not 'A'. The only place where it could potentially have been written is in line 2285, as part of the function call. And, indeed, if I comment out that line, the report goes away.
Note that evalStrArrayCmp() never writes the expr->r parameter. If I change the prototype to explicitely make expt->r const, the warning goes away. So it looks the static analyzer now unerstands that the value cannot change.
Question now: is this a bug or an inherant limit in static analysis?
Extended Description
I have banged my head over this one for quite a while. I think it either is a false positive ... or the construct is too complex for static analysis.
Have a look at the attached report. Keep an eye on variable "expr->r->nodetype". Between points 2 and 7, it never is written. However, the analyzer assumes in step 3 that it's value is 'A' but in step 6 it assumes it has changed to not 'A'. The only place where it could potentially have been written is in line 2285, as part of the function call. And, indeed, if I comment out that line, the report goes away.
Note that evalStrArrayCmp() never writes the expr->r parameter. If I change the prototype to explicitely make expt->r const, the warning goes away. So it looks the static analyzer now unerstands that the value cannot change.
Question now: is this a bug or an inherant limit in static analysis?