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

Fix #12071 (Add safety mode that makes cppcheck more strict about critical errors) #5777

Merged
merged 3 commits into from
Dec 18, 2023

Conversation

danmar
Copy link
Owner

@danmar danmar commented Dec 17, 2023

No description provided.

@danmar danmar requested a review from firewave December 17, 2023 20:15
@danmar
Copy link
Owner Author

danmar commented Dec 17, 2023

@firewave here is another attempt to add more safety compliant analysis. It's now intended to be opt-in.

@danmar danmar merged commit 5aa1710 into danmar:main Dec 18, 2023
@firewave
Copy link
Collaborator

If it would be nice if there would be at least a 24-72 hour grace period on PRs so people actually have a chance to comment on them before they are being merged...

@@ -1066,6 +1066,10 @@ CmdLineParser::Result CmdLineParser::parseFromArgs(int argc, const char* const a
#endif
}

// Safety certified behavior
else if (std::strcmp(argv[i], "--safety") == 0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no unit test for this option in TestCmdlineParser.

There is no documentation either but I do like that because that still allows us to modify this.

I think this should be --safety-exitcode (or rather --critical-exitcode) instead. That would be more alone options we already have and allows people (rather scripts) to differentiate between the type of the failure.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not just about exitcode anymore. It's to enable "safety certified behavior". I envision that this option will not be used much except in our testing. Cppcheck Premium users will get a safety configuration in the cppcheck.cfg file.

}

if (msg.severity == Severity::internal)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have internal errors. So this introduces some ambiguity.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok if you think the name is unfortunate I am not against changing it.

These are messages that the user should never see. They will only be reported internally inside cppcheck. That was my intention with the name.. we have 2 use cases currently:

  • internal logging of executed checkers
  • suppressed critical errors

More use cases could popup later.

if (mSettings.safety && ErrorLogger::isCriticalErrorId(msg.id)) {
mExitCode = 1;

if (mSettings.nomsg.isSuppressedExplicitly(errorMessage, mUseGlobalSuppressions)) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like that we just extended the suppression matrix by factor 2 - it's already way too complex and hard (impossible to me) to understand in code.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is complex for sure already. :-(

It adds complexity but I fear that to pass a safety certification we can't allow that users suppress critical errors by mistake.

@@ -44,3 +44,6 @@ Other:
- Markup files will now be processed after the regular source files when using multiple threads/processes (some issues remain - see Trac #12167 for details).
- Added file name to ValueFlow "--debug" output.
- Fixed build when using "clang-cl" in CMake.

Safety critical fixes:
- Added "--safety" option. It makes Cppcheck more strict about critical errors.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should not be in the release notes as it is not documented.

If we make this official we cannot change this without a transition period and makes it harder to adjust it later on.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. hmm.. I will write this in the proper Cppcheck Premium release notes instead.

I am trying to satisfy conflicting requirements. I can understand that from your point of view this is a quick hack that is not needed. :-(
For Cppcheck Premium the safety certification is very important so we need to satisfy certain requirements, but at the same time I really don't want to make it difficult for existing open source users. Keeping existing open source users happy is also business critical imho.

@firewave
Copy link
Collaborator

Looking at all the hacks we have to add along the way this doesn't look like a good change. It's mostly rather just that - a hack. I get that it serves a purpose but in this way it can only do this temporally so it should not be documented at all.

@firewave
Copy link
Collaborator

I assume this is mainly a change for premium.

And I am wondering if this functionality could simply be achieved by introducing the critical severity internally and leveraging that via an addon. As I have not yet worked with those I am not sure what those could provide.

As mentioned in my previous comments on the original commit I am not seeing much value in this functionality for regular users as those critical errors would include things they cannot fix by themselves as they might also include things which indicate bugs within Cppcheck. So more reason not to make this visible. That needs some reworking but that's yet another rabbit-hole to go down into.

@danmar
Copy link
Owner Author

danmar commented Dec 18, 2023

If it would be nice if there would be at least a 24-72 hour grace period on PRs so people actually have a chance to comment on them before they are being merged...

Sorry.. it was not to avoid your review. As you probably understood I am trying to push out this release.. not at all costs of course, I do not want to introduce last minute bugs now. There are customers waiting for the release and there are post release tasks for customers I am very eager to start working on.

To me 2.13 does not feel perfect from a quality point of view but it's much better than 2.12. We will continue to work on it and 2.14 should be better..

@danmar danmar deleted the fix-12071-3 branch December 20, 2023 21:21
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

Successfully merging this pull request may close these issues.

2 participants