Report undefined pointer dereference in similar way as null pointer dereference.
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.
IMHO I would add the "results in a " part here, as this is part of the process of creating the diagnostic anyway.
Do the null pointer and invalid pointer dereference belong to the same checker, that is called NullDereference?
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.