Should rules be divided to have separate enforcements?

[Xazax-hun]

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]

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]

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