I know per rule 12.3 comma's are not allowed, but in the case of enum I don't see how I can avoid it. Also since shifting it down no longer produces the issue, seems like something needs to be revised here.
Regards,
Amir
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is the command I'm running in case you need it:
cppcheck -rp --inline-suppr --addon=..\cppcheck\misra.json ..\Sources -i ..\BCC -I ..\Sources -I ..\Sources\mcal -I ..\Sources\eal -I ..\Sources\asw
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@aliamir I was tried it with 1.90 version (commit 077e652de), and I can't reproduce it. Please try to update Cppcheck and MISRA addon to actual version and retry it.
If the error can be reproduced after this, I suppose we will need more information about this source code. Is your project is open source?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I pulled the lastest MISRA.py and still get the error. One interesting thing, I've continued to write more code and the problem disappears. I have attached the exact commit where the issue occurs for you guys to investigate, looks like some strange corner case.
Here's the exact error:
..\Sources\asw\aswMcuComm.c:42:11: style: Advisory. The comma operator should not be used. [misra-c2012-12.3]
Thanks for this example. And, no, it doesn't emit R12.3 violation for me.
Here is the complete output of misra.py on my machine:
Checkingaddons/test/misra/aswMcuComm.c.dump...Checkingaddons/test/misra/aswMcuComm.c.dump,config...[addons/test/misra/aswMcuComm.c:124](style)misraviolation(use--rule-texts=<file> to get proper output) (Undefined) [misra-c2012-10.4][addons/test/misra/aswMcuComm.c:243](style)misraviolation(use--rule-texts=<file> to get proper output) (Undefined) [misra-c2012-10.4][addons/test/misra/aswMcuComm.c:139](style)misraviolation(use--rule-texts=<file> to get proper output) (Undefined) [misra-c2012-18.8][addons/test/misra/aswMcuComm.c:140](style)misraviolation(use--rule-texts=<file> to get proper output) (Undefined) [misra-c2012-18.8]MISRArulesviolationsfound:Undefined:4MISRArulesviolated:misra-c2012-10.4(-):2misra-c2012-18.8(-):2
I still believe that you are using an incorrect version of the addon. Please try to use the following commands, specifying an absolute path to latest Cppcheck and MISRA addon:
I would suggest that you bisect your code into some small example that reproduce the problem.. it should be possible to get 10 lines of code that reproduce it.
there could for instance be something in a header that somehow cause this FP.
do you still see the FP if you comment out all the #include lines in the source file?
Last edit: Daniel Marjamäki 2020-06-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I have exactly the same issue (a FP with 12.3). Depending on the amount of code it appears and disappears ... And i can't reproduce this bug with a small example. Is there a possibility of out of bound memory access in the misra.py script ? I have the misra.py script delivered with CppCheck V2.0
Last edit: Jean-Loic MARTIN 2020-07-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a possibility of out of bound memory access in the misra.py script?
No, that's not possible. Internally misra.py uses Python objects defined in cppcheckdata.py (see classes defined at this file). We get these objects by parsing dump file produced by Cppcheck here and here. We are using xml module from Python's standard library, therefore, out-of-bound memory errors are excluded. If you have call the script with correctly generated dump file, it will work as expected.
So I suspect it could be an error in dump file generation routine in Cppcheck itself. To test this, we will need the source code and a dump file that causes misra.py false positives.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I suspect it could be an error in dump file generation routine in Cppcheck itself. To test this, we will need the source code and a dump file that causes misra.py false positives.
I'm afraid i can't send the source code... also the dump file contains the source code...
Don't know how i can help.
I have added code, and now the problem has disappeared.
So when the problem re-appears i will get the dump file and anonymize it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm getting a false positive on the following code:
If I move Address_t below Asw_AutoAddressing_t it no longer produces that issue:
I know per rule 12.3 comma's are not allowed, but in the case of enum I don't see how I can avoid it. Also since shifting it down no longer produces the issue, seems like something needs to be revised here.
Regards,
Amir
Yes I guess that is a false positive. I created ticket https://trac.cppcheck.net/ticket/9779
@danielmarjamaki Can you reproduce this FP?
I was tried it with the following driver code:
And these commands:
Gave me the following output:
I was used Cppcheck from latest
main
branch (commit6756587ac983c73d68605f7596fd157da4488f05
).@aliamir Which version of Cppcheck do you use?
Last edit: Georgiy Komarov 2020-06-18
hmm.. I can't reproduce neither.
I'm using cppcheck 1.90. :
Here is the command I'm running in case you need it:
cppcheck -rp --inline-suppr --addon=..\cppcheck\misra.json ..\Sources -i ..\BCC -I ..\Sources -I ..\Sources\mcal -I ..\Sources\eal -I ..\Sources\asw
What is content of
..\cppcheck\misra.json
? Maybe you are using an outdated version ofmisra.py
script?@aliamir I was tried it with 1.90 version (commit 077e652de), and I can't reproduce it. Please try to update Cppcheck and MISRA addon to actual version and retry it.
If the error can be reproduced after this, I suppose we will need more information about this source code. Is your project is open source?
I pulled the lastest MISRA.py and still get the error. One interesting thing, I've continued to write more code and the problem disappears. I have attached the exact commit where the issue occurs for you guys to investigate, looks like some strange corner case.
Here's the exact error:
..\Sources\asw\aswMcuComm.c:42:11: style: Advisory. The comma operator should not be used. [misra-c2012-12.3]
Thanks for this example. And, no, it doesn't emit R12.3 violation for me.
Here is the complete output of misra.py on my machine:
I still believe that you are using an incorrect version of the addon. Please try to use the following commands, specifying an absolute path to latest Cppcheck and MISRA addon:
amir can you upload the dump file you get also?
I would suggest that you bisect your code into some small example that reproduce the problem.. it should be possible to get 10 lines of code that reproduce it.
there could for instance be something in a header that somehow cause this FP.
do you still see the FP if you comment out all the
#include
lines in the source file?Last edit: Daniel Marjamäki 2020-06-21
Hi all,
I have exactly the same issue (a FP with 12.3). Depending on the amount of code it appears and disappears ... And i can't reproduce this bug with a small example. Is there a possibility of out of bound memory access in the misra.py script ? I have the misra.py script delivered with CppCheck V2.0
Last edit: Jean-Loic MARTIN 2020-07-02
No, that's not possible. Internally misra.py uses Python objects defined in cppcheckdata.py (see classes defined at this file). We get these objects by parsing dump file produced by Cppcheck here and here. We are using xml module from Python's standard library, therefore, out-of-bound memory errors are excluded. If you have call the script with correctly generated dump file, it will work as expected.
So I suspect it could be an error in dump file generation routine in Cppcheck itself. To test this, we will need the source code and a dump file that causes misra.py false positives.
I'm afraid i can't send the source code... also the dump file contains the source code...
Don't know how i can help.
I have added code, and now the problem has disappeared.
So when the problem re-appears i will get the dump file and anonymize it.