Report undefined pointer dereference in similar way as null pointer dereference.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Not sure if this is a good solution. There are few tests that test the undefined reference case. But the added code should work the same way as in the null pointer case?
clang/lib/StaticAnalyzer/Checkers/DereferenceChecker.cpp | ||
---|---|---|
135 | Add "results in a " here? |
Change of the existing error messages and bug category is not necessary but it would be improvement because more uniform error messages. (And not the "logic error" is the best category for this case, if this value is used at all. Other checkers have bad values too.)
I would add one more test for the undefined case. Like a local array variable that is uninitialized. That could mirror some of the null-dereference cases.
clang/lib/StaticAnalyzer/Checkers/DereferenceChecker.cpp | ||
---|---|---|
135 | IMHO I would add the "results in a " part here, as this is part of the process of creating the diagnostic anyway. |
We definitely need more tests. The idea overall however is amazing, thanks!
clang/test/Analysis/misc-ps-region-store.m | ||
---|---|---|
1160 | Is this the entire message? Because traditionally, analyzer warnings start with an upper case and don't terminate. |
Thanks, excellent!
Let's not change warning text without good reasons. Too few of us speak English well enough to check the articles. The original text seems concise and on-point.
Do the null pointer and invalid pointer dereference belong to the same checker, that is called NullDereference?
clang/test/Analysis/misc-ps-region-store.m | ||
---|---|---|
1160 | Full message is: |
I think both SA and Tidy auto-appends the checker's name into the emitted diagnostic. However, @baloghadamsoftware did implement multiple checkers in the same translation unit, so maybe he knows where to override this.
(I can tell you where to override it in the context of Tidy, and it's horribly tricky and ugly...)
Yup. And that's bad.
Note that the only reason to have checker names is to allow users to enable/disable the checkers. Given that enabling/disabling core checkers was never supported to begin with, this wasn't much of an issue. Now that we're moving into the direction of allowing users to silence core checkers without disabling their modeling benefits, this becomes much more of a problem and there's a number of checker name inconsistencies that we'll have to revisit. Another famous inconsistency is having a popular case of null dereference, "calling a C++ method on a null pointer", is in fact checked by the core.CallAndMessage checker rather than by core.NullDereference.
Add "results in a " here?