noisymime

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...