Fix type mismatch of line and column number and add extra information in misra-reports#5407
Fix type mismatch of line and column number and add extra information in misra-reports#5407PeterSchops wants to merge 11 commits into
Conversation
line and column information is of type int everywhere, except in MacroUsage.
I saw that cppcheck was sometimes showing extra information, on what exactly was wrong. And I found this very useful. The extra information is optional, and I'm finding it very helpful to pinpoint the problematic piece of code.
…Usage_line_column_nr
…information_in_error-report
changed reportError(...f"{..}") to reportError(..."{}".format{..})
renamed extra to misra_severity, and added extra as last argument
…n_MacroUsage_line_column_nr Fix type mismatch in MacroUsage
…information_in_error-report
…information_in_error-report
…information_in_error-report
…_extra_information_in_error-report Adding extra information in report for some issues
|
could you show some example output for the extra info. Technically I am not against this extra information. It's just that misra foundation wants that we write the exact error message that Misra has written in the PDF. With NO changes. It was important for them. |
| return False | ||
|
|
||
| def reportError(location, severity, message, addon, errorId, extra=''): | ||
| def reportError(location, severity, message, addon, errorId, misra_severity='', extra=''): |
There was a problem hiding this comment.
Spontanously it does not feel very good to add a "misra_severity" here. This is the generic function it's not related to misra. We have other addons also and I don't want to add various special parameters for those.
So well one approach could be to rename the parameters somehow to have generic parameters that works for all addons..
There was a problem hiding this comment.
I did not technically add the misra_severity, I just renamed the parameter, to the argument name used in misra.py, and then I re-used the extra parameter, for the extra information I wanted to add, since it seemed like a good name for additional error information.
There was a problem hiding this comment.
No it is not a good name for all the other addons.
If I report an error in the misc.py addon and then I want to provide some extra information to the error message then I don't feel that we should use misra_severity.. and I don't want to add more parameters like misc_severity or misc_hint.. I want to reuse the same options.
I want a generic argument name that will make sense in other addons also.
| return | ||
| loc = '[%s:%i]' % (location.file, location.linenr) | ||
| if len(misra_severity) > 0: | ||
| message += ' (' + severity + ')' |
There was a problem hiding this comment.
this code is strange. is the intention to append the misra severity to the message?
Sorry that is not clear to me. I wonder what the xml looks like. Is the extra information added directly to the message text or as extra notes or what.. I don't remember off the top of my head. |
| 'addon': addon, | ||
| 'errorId': errorId, | ||
| 'extra': extra} | ||
| 'extra': misra_severity} |
There was a problem hiding this comment.
why don't we just use the extra. If "extra" has some text (reported from misc.py or any other addon) then why isn't that used in the output?
There was a problem hiding this comment.
I did not use extra, because today in misra.py misra_severity is stored in the extra field.
When I look in the cppcheck XML output I find following fields:
- id: misra_2012_x_y
- severity: would be ideal for the severity information
- msg: place for the error message from the file
- verbose: the place for extra information
- cwe
- file0
- location of the error
I use my own reportError function, that does write a XML-file, that is close to what cppcheck creates today. And I did not want to change the reportError function provided in cppcheckdata.py significantly to avoid any problems.
So since misra.py writes severity information twice (cppcheck_severity and misra_severity)
https://github.com/danmar/cppcheck/blob/a87e9e104239785058e91811ea1dbf5bdc44e919/addons/misra.py#L4132
I could remove the misra_severity from misra.py, and replace that with extra or verbose information. But then I might break something when the misra checks are called through cppcheck, because then the --cli option seems to get added automatically. And the misra_severity could be used somewhere.

I would like to get the extra information inside, so if you can tell me how you would like me to update the code. I will try to prepare the update.
There was a problem hiding this comment.
I use my own reportError function, that does write a XML-file, that is close to what cppcheck creates today
I do not see that here in this PR.. do you have some special function locally that writes different xml file?
There was a problem hiding this comment.
I'm using cppcheck since 1.80, and misra.py evolved a lot. I customized some checks, to not show certain issues, added custom checks, .. and to avoid merging misra.py with mine, I added a wrapper around the misra.py, and it has a XML-write feature, but I can't recall why I did that.
I'm using the python script with the dump-files generated by cppcheck, I'm not sure if misra.py can write XML-files when used as standalone.
It was also not my intention to change anything there. I just want to add some extra/verbose information in the reports, and contribute to the tool, so it can benefit everybody.
|
Please give me the details.
I do not want to write an example code myself and then apply these changes and then testrun it to see exactly what it looks like :-( Run cppcheck like so: then please show what yourtestfile.c, out.xml and out.txt says.. |
I usually run misra.py on the dump-files created by cppcheck. But I can also try this, and provide the output. I appreciate your feedback. And I realize the way I updated the reportError function was not the best. |
|
cppcheck --addon=misra --enable=style misra-test-c.cpp --xml 2> out.xml In the XML-file I see use --rule-texts=, but when I try that, cppcheck tells me it is a unrecognized option. So I tried then with using the dump-file as intermediate step, so that I can call the python code directly. And this gives me this: MISRA rules violations found: MISRA rules violated: Where the 7.2 has extra information. I'm always using the dump-file method, because that is working for me, but I was wondering
I also figured out that I need to use misra.json to pass the --rule-texts to cppcheck And to finish it, I included the output my script generated. This XML only contains the misra errors. (I wanted cppcheck and misra seperate, since misra is more strict than cppcheck. So an error flagged by cppcheck is more serious then one flagged by misra.py) Conclusion:
So the msg in the if --cli part of cppcheckdata.py needs to be updated in one way or the other, to make this feature useful for all users. |
|
The parsing of reportError data from cppcheckdata.py seems to be done here in cppcheck.cpp I see multiple things written in the json-dump getting decoded.
But extra seems not to be used. |
If I am not mistaken the misra.py will save the ctu-info summaries when you check the dump files. But no warning is reported. To perform the analysis and get warnings you need to invoke misra.py at the end after all dump files have been checked and provide the list of ctu-info files.
That is correct. I think that using cppcheck as frontend is the "recommended" way. I am not against that you call misra.py directly but I basically feel I am not very interested to duplicate and maintain the same frontend features in both the addon and core cppcheck. |
I am actually not sure. If we really want that the warning text will be identical with the rule text in the misra specification then I think it would be best to add the extra information in an additional note. |
|
If the expected cppcheck xml output is this: then maybe the corresponding addon output could look something like this: without newlines. Cppcheck could support both formats.. cppcheckdata.reportError could print the old compact format when extra notes are not needed. |
ok I understand. It feels good. Probably it would be OK to remove extra from the --cli output. |
When I look at the XML-code generated by cppcheck, I see that the msg and verbose are not always identical. And I wanted to get the extra information to end up in the verbose section. Since that is where the helping is provided to the user is ending up for cppcheck reports today. |
I'm passing only a list of all the dump-files. So I will need to make some changes.
Could I use multiple scripts at once with cppcheck?
I completely understand that. It is already a big code base, where C++ and Python are combined. And I tried to fix a number of mismatches between the cppcheckdata.py and the information written in the dump-files. It was not a small task. |
ok that is an option.. but then the warning text will not be identical to the rule text in the misra specification. If you call cppcheck like this: Then cppcheck will print the "message" text. without the extra information. If you call cppcheck like this: Then the "message" is not written. But the "verbose" message is written instead. If that just contains your extra information then cppcheck will not write the rule text at all. |
It sounds like the html-generation should be updated so it's consistent with cppcheck. If it prints both the "msg" string and "verbose" string that is not consistent. |
well it's mentioned but it's hard to extract the information. the "id" in the xml is "{addon}-{errorId}" from the addon cli output. at least you can say that:
|
|
Thanks for the input, I don't have time to continue with this for the moment. But when I have some spare time I will continue. |


Make sure that useline and usecolumn are always of type integer in the python scripts.
Add extra information in misra-reports, for a number of checks, to make it easier to know what is exactly wrong.