You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the rules cover a wide range of errors each of which might have a different enforcement in the static analysis tool that is checking for guideline violations.
One example is:
Lifetime.1: Don’t dereference a possibly invalid pointer: detect or avoid.
There are many ways for a pointer to be invalid:
It can be a nullpointer
It can be a pointer from an unsafe cast
It can be uninitialized
It can be out of bounds
It can be a moved-from smart pointer
The pointee could have been deallocated
Individual static analysis tools are likely to detect all these errors in separate checks. Users trying to suppress a false positive using [[gsl::suppress(lifetime.1)]] might end up suppressing more than they wanted. It would be nice to give users more granularity, so they can express which aspect of the lifetime error is a false positive, so other checks have a chance to detect other kinds of lifetime errors after the code changes.
Another example is:
R.1: Manage resources automatically using resource handles and RAII (Resource Acquisition Is Initialization)
While the general principle is well captured in the rule, many static analysis tools have specialized versions that can find particular instances of this problem, like:
Memory leaks
Forgot to unlock a lock
Forgot to close a file handle
etc..
The text was updated successfully, but these errors were encountered:
Editors call: We want the rules to be general because they are aimed at programmers, and the Enforcements to be specific because they are aimed at tool implementers.
Perhaps we should numbering the Enforcements for each rule, so that people writing portable code would be able to turn them on and off with the same results across Guideline checker implementations. Would that address your concern?
Editors call: Thanks! Sorry for the lag on this. We decided on #2178 to not suppress specific Enforcements. The model is that if a rule is active all its Enforcements are active too.
Some of the rules cover a wide range of errors each of which might have a different enforcement in the static analysis tool that is checking for guideline violations.
One example is:
There are many ways for a pointer to be invalid:
Individual static analysis tools are likely to detect all these errors in separate checks. Users trying to suppress a false positive using
[[gsl::suppress(lifetime.1)]]
might end up suppressing more than they wanted. It would be nice to give users more granularity, so they can express which aspect of the lifetime error is a false positive, so other checks have a chance to detect other kinds of lifetime errors after the code changes.Another example is:
While the general principle is well captured in the rule, many static analysis tools have specialized versions that can find particular instances of this problem, like:
The text was updated successfully, but these errors were encountered: