How to get Coverity static analysis compatible with C++0x standard?

11,612

Solution 1

Workaround by Coverity Support:

The inline namespace is a known bug in Coverity. To bypass it, configure Coverity with the following additional options (in the config file):

  <begin_command_line_config></begin_command_line_config> 
  <add-arg>--ppp_translator</add_arg> 
  <add_arg>replace/inline namespace ([_a-zA-Z0-9]*)\s+\{\s*\}/namespace $1 { } using namespace $1;</add_arg> 
</options>

After that we got some other errors but they seem to belong all to string definitions. Now add a Coverity define at the beginning of coverity-compiler-compat.h (also in the config dir):

#define __COVERITY_NO_STRING_NODEFS__

After these changes the cov-build runs without errors and the analysis can be started.

Solution 2

Your library implementation is using C++11. Presumably there are #ifdefs that remove all the C++11 stuff when you do call g++ with -std=c++98 but it seems that however Coverity is integrated with g++, it's not defining the same things that are necessary to avoid the C++11 features.

You should figure out what the macros that gcc uses around that C++11 code are and then make sure that Coverity is defining them appropriately as well when it analyzes your project.

Share:
11,612
Indimental
Author by

Indimental

Updated on June 18, 2022

Comments

  • Indimental
    Indimental about 2 years

    I am using a Wind River Compiler 4 (gcc (C) and g++ (C++)) and it compiles all my projects without any problems. Now I have to use Coverity Static Analysis to check my code. I have configured the specific compilers. For the C-Code (gcc) there are no problems and I can run the analysis, but for the C++-Code (g++) I got a lot of errors:

    .../c++config.h", line 214: error #40:
        expected an identifier
    inline namespace __gnu_cxx_ldbl128 { }
           ^
    
    .../c++config.h", line 214: error #326:
        inline specifier allowed on function declarations only
    inline namespace __gnu_cxx_ldbl128 { }
    ^
    
    .../c++config.h", line 214: error #65:
        expected a ";"
    inline namespace __gnu_cxx_ldbl128 { }
                                       ^
    .../include/string.h", line 76: error #312:
        cannot overload functions distinguished by return type alone
    extern __const void *memchr (__const void *__s, int __c, size_t __n)
                         ^
    
    .../include/string.h", line 116: error #312:
        cannot overload functions distinguished by return type alone
    extern "C++" __const void *memchr (__const void *__s, int __c, size_t __n)
                         ^
    

    It seem to be some C++11 specific features like the inline namespace but the code doesn't use these features. The errors above are produced with a HelloWorld-Code:

    #include "stdio.h"
    #include "util.h"
    #include <string>
    #include "string.h"
    
    using namespace std;
    
    int main()
    {
        printf("Hello World, C++ version: %d.%d.%d\r\n",__GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__);
    
        return 0;
    }
    

    I have tried to set the c++ standard with the g++ option

    -std=c++98
    

    but the result doesn't changed.

    The Test-Code is in a big build hierarchy but the steps for Coverity are like this:

    1. target and env set (Wind River 4 Linux)
    2. make clean
    3. cov-configure with compiler dir and type
    4. cov-build with the correct "make all" command that works alone
    5. cov-analyze
    6. if (no_error) cov-commit-defects

    I have also configured Coverity to replace all "inline namespace" with "namespace" during the cov-build (--ppp-translator replace/inline namespace/namespace). The inline errors disappeared but it produces more of this overload errors and no succecfully build. Also tried to remove the "C++" the same way but didn't work there are always more errors.

    Does anybody have an idea what is the problem here? And how can I get the Coverity build without errors? Maybe I can configure Coverity to ignore c++ standard headers but I don't now how?

  • Indimental
    Indimental over 12 years
    That's the problem I have never used this "inline" and don't know why it is in there. I forgot to write that I have also configured Coverity to replace all "inline namespace" with "namespace" but then there appear more problems like the last both.
  • bames53
    bames53 over 12 years
    inline namespaces are a C++11 feature. It's mainly for versioning a library implementation.
  • bames53
    bames53 over 12 years
    @Indimental you can't just replace inline namespaces with namespaces, they don't do the same thing, so the library implementation just won't work and Coverity won't have any hope of analyzing it correctly.
  • Indimental
    Indimental over 12 years
    @bames53 year, you are right but I thought I didn't use them and want only a way to get Coverity do anything. Actually I already removed all these replacements.
  • Indimental
    Indimental over 12 years
    It seems that there are a few defines discribed here: stackoverflow.com/questions/2958398/… but I can't find any connection to the error lines. The error lines have to do with long double 128 bit model and depend not of one of the c++0x defines. I must also say that I'm totaly new to such depth compiler stuff.
  • bames53
    bames53 over 12 years
    Did the error messages from Coverity change when you made Coverity use those C++0x defines? There may be other defines you need. You can make gcc list everything it defines and then use that as a basis for what you need to define for Coverity, or you can just examine the header files to see what they check for.
  • Indimental
    Indimental over 12 years
    When I use the C++0x standard, the first 3 errors are the same. The last both are replaced by errors in "stringfwd.h": identifier "char32_t" is undefined: template<> struct char_traits<char32_t>; same for "char16_t" identifier. Can it be that Coverity build includes some default headers and that they are incompatible with the native includes? So there is something overwritten and chrashes the header config.
  • bames53
    bames53 over 12 years
    I suppose that could be. Also it could be that GCC's headers still use some C++11 features even when you disable C++11 support, and that GCC is made to work with that.