Menu

Error when printing dictionary in addon

samed
2020-12-07
2020-12-10
  • samed

    samed - 2020-12-07

    When Cppcheck is invoked from CLI with addon, following error is thrown if addon tries to print a dictionary.

    Bailing out from checking Source.cpp since there was an internal error: "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.

    Bailing out from checking Source.cpp since there was an internal error: Failed to execute 'python.exe <path> --cli Source.cpp.dump'.
    
     
  • Daniel Marjamäki

    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;

    cppcheck --dump somefile.c && python3 youraddon.py somefile.c.dump
    

    ... with that approach you can print whatever you want

     

    Last edit: Daniel Marjamäki 2020-12-07
  • samed

    samed - 2020-12-08

    the addons are not supposed to print stuff on stdout when executed from Cppcheck.

    Didn't know that. If that's the case it's fine.

     
    • Richard Smith

      Richard Smith - 2020-12-08

      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?

       
  • Daniel Marjamäki

    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
    • Richard Smith

      Richard Smith - 2020-12-08

      sorry I do not understand this one.

      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.

       
  • Daniel Marjamäki

    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.

     
    • Richard Smith

      Richard Smith - 2020-12-10

      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.

      ../../build/bin/cppcheck --dump --inline-suppr --suppressions-list=suppressions.txt ./misra/m1.c ./misra/m2.c
      python3 ../misra.py --show-suppressed-rules ./misra/*.dump
      
      rsmith@rsmith-xps13:/home/src/cppcheck.git/addons/test$ cat suppressions.txt 
      MISRA_15_3:file2.c:74
      MISRA_20_1:m1.c:9999
      
      Checking misra/m1.c ...
      1/2 files checked 50% done
      Checking misra/m2.c ...
      2/2 files checked 100% done
      Checking ./misra/m1.c.dump...
      Checking ./misra/m1.c.dump, config ...
      [misra/m1.c:3] (style) misra violation (use --rule-texts=<file> to get proper output) (Undefined) [misra-c2012-15.1]
      [misra/m1.c:3] (style) misra violation (use --rule-texts=<file> to get proper output) (Undefined) [misra-c2012-15.2]
      Checking ./misra/m2.c.dump...
      Checking ./misra/m2.c.dump, config ...
      [misra/m2.c:3] (style) misra violation (use --rule-texts=<file> to get proper output) (Undefined) [misra-c2012-15.1]
      [misra/m2.c:3] (style) misra violation (use --rule-texts=<file> to get proper output) (Undefined) [misra-c2012-15.2]
      
      MISRA rules violations found:
              Undefined: 4
      
      MISRA rules violated:
              misra-c2012-15.1 (-): 2
              misra-c2012-15.2 (-): 2
      Suppressed Rules List:
        20.01: m1.c: 9999 (0 locations suppressed)
        15.03: file2.c: 74 (0 locations suppressed)
      

      No message from cppcheck but --show-suppressed-rules clearly shows what suppression was defined for that rule.

       
  • Richard Smith

    Richard Smith - 2020-12-10

    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
    
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.