Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should rules be divided to have separate enforcements? #1799

Closed
Xazax-hun opened this issue Jun 24, 2021 · 3 comments
Closed

Should rules be divided to have separate enforcements? #1799

Xazax-hun opened this issue Jun 24, 2021 · 3 comments
Assignees

Comments

@Xazax-hun
Copy link

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..
@hsutter
Copy link
Contributor

hsutter commented Aug 19, 2021

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?

@Xazax-hun
Copy link
Author

Yeah, I think this sounds reasonable and would address this issue.

@hsutter
Copy link
Contributor

hsutter commented Feb 15, 2024

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.

@hsutter hsutter closed this as completed Feb 15, 2024
@hsutter hsutter self-assigned this Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants