Menu

cppcheck not detecting basic flaw (but it was)

Joe Filion
2016-09-23
2016-11-11
  • Joe Filion

    Joe Filion - 2016-09-23

    I built the 1.75 version in LInux (Mint) and as I was setting up my environment I added this to my code:

    char test[5];
    test[5] = 'x';

    cppcheck caught this error, but I didn't have everything setup yet. Once I included the include paths for my build and my -D switches, it no longer picks up this purposely added flaw. I also changed the order of member variable initialization in one of my objects to be out of order from the definitions in the header, but cppcheck didn't notice. The odd thing is that cppcheck is catching some problems (mosty style but some performance). I have --enable=all set. Has anyone else had this problem and is there an easy solution?

     
  • Joe Filion

    Joe Filion - 2016-09-23

    Update: I just dropped back to an older version (1.61 from the Linux Mint SW repository) and it appears to be working. Actually, the out of order member initialization is still not being caught, but I am now seeing the "arrayIndexOutOfBounds" error.

     
  • Mr. X

    Mr. X - 2016-09-25

    If the code is inside a function, cppcheck 1.75 should detect it (and it does, I just tested it).

     
  • Joe Filion

    Joe Filion - 2016-09-26

    It worked for me as well in 1.75 until I added in all of my include paths and -D switches. Then it stopped detecting it. I guess I was asking if anyone had any idea on what could cause it to stop working. Is there some kind of limit I'm bumping up against or is there any way to debug this? I tried turning on the debug switch which as I understand it is supposed to explain why a check bails, but it didn't show anything for code I'm questioning.

     
  • Mr. X

    Mr. X - 2016-09-26

    In general it is not recommended to provide each and every include path. Especially C or C++ standard library header path should not be given.

    If you use -D, it stops configuration splitting unless you also give -f or --max-configs=...

     

    Last edit: Mr. X 2016-09-26
  • Joe Filion

    Joe Filion - 2016-09-26

    I'm only including the include paths to my code as I had read in the documentation to avoid including the standard libraries. I'm sorry, but I'm a bit confused by your terminology "configuration splitting." I guess I thought a single configuration would result if every pre-processor switch in the code were given a value, and that the way to end up with more configurations would be if cppcheck didn't know about a switch and had to start following multiple paths. I suspect my thinking is wrong in this regard. Could you please clarify what you mean by "configuration splitting?" Thanks.

     
  • Mr. X

    Mr. X - 2016-09-26

    configuration splitting means that cppcheck checks all branches for #ifdef directives where it does not know whether they evaluate to true or not. If you use -D (without -f), it only checks the configuration with the given macros being defined.

     
  • Daniel Ellis

    Daniel Ellis - 2016-11-11

    I have noticed a similar problem when including additional headers. This particular problem was introduced in 1.71

    I have raised the following ticket http://trac.cppcheck.net/ticket/7810

     

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.