The alpha.core.CastToStruct warns when for instance casting a int pointer to a struct pointer. As accessing a field can lead to memory access errors.
This patch improves the checker so it also warns about widening casts of structs.
Differential D23508
Improve alpha.core.CastToStruct warn about widening casts of structs also danielmarjamaki on Aug 15 2016, 6:31 AM. Authored by
Details
The alpha.core.CastToStruct warns when for instance casting a int pointer to a struct pointer. As accessing a field can lead to memory access errors. This patch improves the checker so it also warns about widening casts of structs.
Diff Detail
Event TimelineComment Actions Could we re-use some code between the two checks, like obtaining the type of the operands, and throwing the bug report? P.S. A thing to notice: this checker shouldn't be path-sensitive, it doesn't use any path-sensitive information. Comment Actions
Yes I do wonder about that. As the checker is written right now it seems to me it could be moved to clang-tidy. But I am thinking we could use path-sensitive analysis in this check and see if the cast leads to memory access problems. Comment Actions
Yeah, in particular, we could also see if the suspicious cast is actually a revert of a previous cast. No way it's blocking this review though. Comment Actions Thanks!! It looks a lot better now.
Comment Actions Thanks for the tests!
Comment Actions Ping.
Comment Actions This patch seems to be an improvement for the original checker, and i think it should be ok to commit if your evaluation of the new check shows reasonable true positive rate. However, if i was to choose, based on this discussion and other experiences, i would have wished this checker go in a different direction: make a single checker for violations of the strict aliasing rule. This should be do-able as a classic path-sensitive checker which would warn if the same object (RegionOffset) is accessed assuming incompatible value types. For symbolic void* or char* pointers, such checker would need to catch two accesses (which forces us to register stuff with program state), while for other pointer symbols and for concrete regions perhaps a single access should be enough to detect the problem. Such checker would probably be improved by finding branches that introduce aliases between pointer symbols, eg. void foo(int *x, struct S *y) { if (x == y) { ... } } which we don't handle very well in the path-sensitive engine, but it's a great place to start looking into this. I wish somebody looked into this, because it sounds like a really good task for the analyzer.
Comment Actions
That is reasonable. Ideally everybody would fix all UB. As far as I know it's common to break the strict aliasing rule. There are users that would rather use -fno-strict-aliasing than fix their code. I want to have a checker that is useful when -fno-strict-aliasing is used and detects access out of bounds. |