Menu

Avoiding duplicateBreak on functions requiring return values.

2019-06-04
2019-06-11
  • Clint Chelak

    Clint Chelak - 2019-06-04

    I have functions in my company code that have non-void return types but can find themselves with a runtime NEED_CODE exception to be thrown for scenarios we need to address but haven't finished the logic for. An example of an unfinished function below.

     int myFutureFeature()
     {
       NEED_CODE; // A macro set by our company to throw an exception with message
       return 0;
     }
    

    In these scenarios, we will trigger duplicateBreak conditions in cppcheck if we leave the return statement after the exception, and compile time warnings if we don't (if I remember correctly). I'm thinking of suppressing duplicateBreak, though it has found valid cases before. Is there a modification to the code I can consider to fix this issue of consecutive breaks?

     
  • Clint Chelak

    Clint Chelak - 2019-06-04

    A More Complex Scenario: Text substitution

    Here is the scenario I'm truly stuck on which is not as simple as removing the function. Cppcheck has been good in sparking discussions on whether we still have plans to develop functions such as the ones above, but there are cases where I don't have a choice in removing a function.

    The following is an example (roughly) found in our code (I've tried to simplify it to illustrate the concern). The macro below serves as a wrapper function for an interface. It selects and calls the appropriate version of a math function (CUDA-based or C++ based).

    #ifdef HAVE_CUDA
    #define MATH_CUDA(func, ret...) \
      do { \
        if (wantCuda_){ \
          return mathCuda.func; \
        } \
        else { \
          NEED_CODE; \
          return ret; \
        } \
      } while (0)
    #else
     #define MATH_CUDA(func, ret...) \
      do { \
        NEED_CODE; \
        return ret; \
      } while(0)
    #endif
    

    It's easy to see duplicateBreak being thrown when the prepocessor directive HAVE_CUDA is not defined. It will simply throw a NEED_CODE exception and then give whatever return type was needed by the compiler. The two returns are redundant, but (I think) needed to compile without warnings.

     
  • Paul Fultz

    Paul Fultz - 2019-06-10

    You could add a CPPCHECK define when checking with cppcheck and then define NEED_CODE as:

    #ifdef CPPCHECK
    // Do nothing
    #define NEED_CODE
    #else
    #define NEED_CODE throw std::runtime_error("Need code");
    #endif
    
     
  • Clint Chelak

    Clint Chelak - 2019-06-11

    Thanks for the response. The solution we found was very similar, putting #ifndef CPPCHECK around those macros. It proved to create fewer false positives than commenting out the NEED_CODE exception through macros.

     

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.