Activity for noisymime
-
noisymime modified a comment on discussion General Discussion
It took me a while to track this down, but I finally figured out why nameTokenId and scopeId were occassionally having their value come through as "0x0". It turns out that if you're running cppcheck over a file that #includes a header file, and that header file in turn has an #include to another header file, then arguements of any function defined in that final header file will come through as having nameTokenId and scopeId set to 0x0. Eg: someFile.c global.h someOtherFile.h someFile.c has: #include...
-
It took me a while to track this down, but I finally figured out why nameTokenId and scopeId were occassionally having their value come through as "0x0". It turns out that if you're running cppcheck over a file that #includes a header file, and that header file in turn has an #include to another header file, then arguements of any function defined in that final header file will come through as having nameTokenId and scopeId set to 0x0. Eg: someFile.c global.h * someOtherFile.h someFile.c has: #include...
-
It took me a while to track this down, but I finally figured out why nameTokenId and scopeId were occassionally having their value come through as "0x0". It turns out that if you're running cppcheck over a file that #includes a header file, and that header file in turn has an #include to another header file, then arguements of any function defined in that final header file will come through as having nameTokenId and scopeId set to 0x0. Eg: someFile.c global.h * someOtherFile.h someFile.c has: #include...
-
Here's a little minimum test from one or the files I'm using. It produces a bunch of scopeId = 0x0 results causing the script to crash out. Not sure if related, but it also produces a bunch of false-positives on misra 5.4 in globals.h. The only reason I wonder if it's related is because the false-positive is a result of the scope of the macro definitions not being taken into account (ie the macro is declared in multiple places, but all within a series of exclusive #if #elif statements). This same...
-
Not sure if this helps at all, but it looks like the elements that it's failing on are all function arguments. If I get the script to print out the ID when it hits one with a 0x0 scopeId, they're all function arguments that show in the dump file like: <var id="0x7fcbb48e1890" nameToken="0x0" typeStartToken="0x7fcbb2f0c5a0" typeEndToken="0x7fcbb2f0c5a0" access="Argument" scope="0x0" constness="0" isArgument="true" isArray="false" isClass="false" isConst="false" isExtern="false" isLocal="false" isPointer="false"...
-
I've been using the Misra validator for a while now, but had frozen my project against v1.79 in order to have a consistant target. With the supression feature now in place though, I'm now looking at moving up to the latest release (1.86), but ran into a bunch of errors when running the misra.py script. Long story short, a number of elements were reaching Variable.setId() in cppcheckdata.py with values of 0x0, which caused the script to crash out. Specifically these were the nameTokenId and scopeId...
-
I've been using the Misra validator for a while now, but had frozen my project against v1.79 in order to have a consistant target. With the supression feature now in place though, I'm now looking at moving up to the latest release (1.86), but ran into a bunch of errors when running the misra.py script. Long story short, a number of elements were reaching Variable.setId() in cppcheckdata.py with values of 0x0, which caused the script to crash out. Specifically these were the nameTokenId and scopeId...
1
