Fix #11353 FP uninitvar for struct member set via pointer#5314
Fix #11353 FP uninitvar for struct member set via pointer#5314orbitcowboy merged 2 commits intocppcheck-opensource:mainfrom
Conversation
| bool match(const Token* tok) const override | ||
| { | ||
| return SubExpressionAnalyzer::match(tok) || | ||
| (Token::simpleMatch(tok->astParent(), ".") && SubExpressionAnalyzer::match(tok->astParent())); |
There was a problem hiding this comment.
Why are we matching the token when the parent matches? That seems wrong.
There was a problem hiding this comment.
Otherwise x (in s.x, lifeTok) and s (expr) don't match.
There was a problem hiding this comment.
I see, we probably need to create a different match function for this purpose as there are other uses like this that will suffer the same issue.
| continue; | ||
|
|
||
| valueFlowForward(start, tok->scope()->bodyEnd, var->nameToken(), uninitValue, tokenlist, settings); | ||
| if (result.terminate != Analyzer::Terminate::Modified) |
There was a problem hiding this comment.
This seems strange. Why are we skipping forwarding only when the last variable in the list terminates as modified?
There was a problem hiding this comment.
This happens for every variable, right?
Why are there even two forwards? Anyway, the second call was setting an uninit value (for return s) when the MemberExpressionAnalyzer had terminated after an assignment, so I tried to prevent that.
There was a problem hiding this comment.
This happens for every variable, right?
Why are there even two forwards?
There is a forward for every variable in the struct.
Anyway, the second call was setting an uninit value (for return s) when the MemberExpressionAnalyzer had terminated after an assignment, so I tried to prevent that.
But this starts at the same spot, so why does the last valueFlowForward not catch the assignment?
There was a problem hiding this comment.
My thinking was, because it doesn't do the special MemberExpressionAnalyzer stuff?
There was a problem hiding this comment.
Yea thats it. And the special matching stuff is too just match the lifetimes since we point to class variables. Ideally, we should update the lifetime to point to the correct token, but this would require changing a lot of assumptions through out.
3 participants
No description provided.