When Cppcheck is invoked from CLI with addon, following error is thrown if addon tries to print a dictionary.
BailingoutfromcheckingSource.cppsincetherewasaninternalerror:"type mismatch! call is<type>() before get<type>()"&&is>std::string>()
Print statement: print(dictionaryName)
If I try to print this way: print(*dictionaryName) then following error is thrown, although the keys of dictionary is printed. I've seen this error thrown in some other cases where python code still completely executes.
ok that is maybe a problem. the addons are not supposed to print stuff on stdout when executed from Cppcheck. Cppcheck reads the errors from stdout and that is supposed to be valid json. We could have a better validation and throw a nicer error from cppcheck.
if you use cppcheckdata.reportError in the addon to print debug messages then you should get the output on the screen.
but you can also try to execute the addon separately;
The misra.py addon has options that generate output. --show-suppressed-rules and --verify-rule-texts are examples. --verify-rule-texts could be run on its own but --show-suppressed-rule is designed to be a diagnostic tool to see what rule suppressions have been enabled and won't be very useful without output in the cppcheck context case.
In addition the misra addon has print() statements for many of the error conditions.
How should the addon report back a message to cppcheck that can be displayed to the user?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In addition the misra addon has print() statements for many of the error conditions.
ouch. I would suggest some cppcheckdata.reportError() output with the severity 'information' or 'debug'. or check if '--cli' command line parameter has been used. If the '--cli' has not been used then feel free to print whatever on stdout..
--show-suppressed-rule is designed to be a diagnostic tool to see what rule suppressions have been enabled and won't be very useful without output in the cppcheck context case.
sorry I do not understand this one.
I thought the point of that was only for those that want to run misra addon standalone.
It seems to me we have some diagnostic tools in the misra addon and then some other diagnostic tools in cppcheck. Imho I would prefer that we just rely on cppcheck internal diagnostics..
In Cppcheck we have the unusedSuppression warning. All suppressions that do not get that warning are used.
Last edit: Daniel Marjamäki 2020-12-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought the point of that was only for those that want to run misra addon standalone.
When that option was created the only way to run addons was via --dump and running the addon directly. There was no thought on standalone vs inside cppcheck.
With the incorporation of running addons inside the cppcheck context many of these existing behaviors are no longer in sync with how an addon needs to behave.
The use case for this option is the following scenario:
One of my team members contacts me and says Hey, Richard. I'm having problems with rule X.(most often a false positive) and I'm trying to add a suppression for it but its not working.
The 1st step diagnostic in this case is to run the check with --show-suppressed-rules. This option will display every rule that has been setup to be suppressed. If the rule exists in that list and matches the desired part of the code then I have to dig deeper. But usually it is a simple mistake in defining the rule or the line number doesn't match the code location.
It seems to me we have some diagnostic tools in the misra addon and then some other diagnostic tools in cppcheck. Imho I would prefer that we just rely on cppcheck internal diagnostics..
I completely agree and with --addon that seem to be the only way it can be done. However, this ability does not exist in cppcheck currently so it must be added before it can be used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When that option was created the only way to run addons was via --dump and running the addon directly. There was no thought on standalone vs inside cppcheck.
Yes.
The 1st step diagnostic in this case is to run the check with --show-suppressed-rules.
So.. you want to debug a suppression that does not work.
If you specify the wrong location for the suppression or write the wrong error-id etc.. you should get a unusedSuppression warning. The --show-suppressed-rules would contain the suppression (with the same information?).
If you get no unusedSuppression warning then I would say cppcheck does not even understand that you added a suppression. The --show-suppressed-rules will not show the suppression neither.
I do not personally see that --show-suppressed-rules can tell you anything particularly useful that you don't see now anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So.. you want to debug a suppression that does not work.
Yes.
If you specify the wrong location for the suppression or write the wrong error-id etc.. you should get a unusedSuppression warning. The --show-suppressed-rules would contain the suppression (with the same information?).
For the entire time I have been using cppcheck I have never seen this message. It does not appear to work in this case.
When Cppcheck is invoked from CLI with addon, following error is thrown if addon tries to print a dictionary.
Print statement:
print(dictionaryName)
If I try to print this way:
print(*dictionaryName)
then following error is thrown, although the keys of dictionary is printed. I've seen this error thrown in some other cases where python code still completely executes.ok that is maybe a problem. the addons are not supposed to print stuff on stdout when executed from Cppcheck. Cppcheck reads the errors from stdout and that is supposed to be valid json. We could have a better validation and throw a nicer error from cppcheck.
if you use cppcheckdata.reportError in the addon to print debug messages then you should get the output on the screen.
but you can also try to execute the addon separately;
... with that approach you can print whatever you want
Last edit: Daniel Marjamäki 2020-12-07
Didn't know that. If that's the case it's fine.
I didn't know that either.
The misra.py addon has options that generate output. --show-suppressed-rules and --verify-rule-texts are examples. --verify-rule-texts could be run on its own but --show-suppressed-rule is designed to be a diagnostic tool to see what rule suppressions have been enabled and won't be very useful without output in the cppcheck context case.
In addition the misra addon has print() statements for many of the error conditions.
How should the addon report back a message to cppcheck that can be displayed to the user?
ouch. I would suggest some
cppcheckdata.reportError()
output with the severity 'information' or 'debug'. or check if '--cli' command line parameter has been used. If the '--cli' has not been used then feel free to print whatever on stdout..sorry I do not understand this one.
I thought the point of that was only for those that want to run misra addon standalone.
It seems to me we have some diagnostic tools in the misra addon and then some other diagnostic tools in cppcheck. Imho I would prefer that we just rely on cppcheck internal diagnostics..
In Cppcheck we have the
unusedSuppression
warning. All suppressions that do not get that warning are used.Last edit: Daniel Marjamäki 2020-12-08
When that option was created the only way to run addons was via --dump and running the addon directly. There was no thought on standalone vs inside cppcheck.
With the incorporation of running addons inside the cppcheck context many of these existing behaviors are no longer in sync with how an addon needs to behave.
The use case for this option is the following scenario:
One of my team members contacts me and says Hey, Richard. I'm having problems with rule X.(most often a false positive) and I'm trying to add a suppression for it but its not working.
The 1st step diagnostic in this case is to run the check with --show-suppressed-rules. This option will display every rule that has been setup to be suppressed. If the rule exists in that list and matches the desired part of the code then I have to dig deeper. But usually it is a simple mistake in defining the rule or the line number doesn't match the code location.
I completely agree and with --addon that seem to be the only way it can be done. However, this ability does not exist in cppcheck currently so it must be added before it can be used.
Yes.
So.. you want to debug a suppression that does not work.
If you specify the wrong location for the suppression or write the wrong error-id etc.. you should get a unusedSuppression warning. The
--show-suppressed-rules
would contain the suppression (with the same information?).If you get no unusedSuppression warning then I would say cppcheck does not even understand that you added a suppression. The
--show-suppressed-rules
will not show the suppression neither.I do not personally see that
--show-suppressed-rules
can tell you anything particularly useful that you don't see now anyway.Yes.
For the entire time I have been using cppcheck I have never seen this message. It does not appear to work in this case.
No message from cppcheck but --show-suppressed-rules clearly shows what suppression was defined for that rule.
Similar behavior. with --addon. No message.
../../build/bin/cppcheck --inline-suppr --suppressions-list=suppressions.txt --addon=misra.py ./misra/m1.c ./misra/m2.c Checking misra/m1.c ... misra/m1.c:3:4: style: misra violation (use --rule-texts=<file> to get proper output) [misra-c2012-15.1] goto x; ^ 1/2 files checked 50% done Checking misra/m2.c ... misra/m2.c:3:4: style: misra violation (use --rule-texts=<file> to get proper output) [misra-c2012-15.1] goto x; ^ 2/2 files checked 100% done