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

3

7

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?

Lenwood answered 19/1, 2012 at 14:56 Comment(4)
What version of gcc are you using? 4 is not specific enough. Anyway, you should open a case with [email protected] - send them your build log and preprocessed source and they will be able to tell you what you need to add to your configuration to allow cov-emit to successfully process it.Metagnathous
The WindRiver Env. is WR-Linux-4.0/Toolchain-4.4-291 and the gcc that is used seems to be the version 4.4.1. That is the version of the include dir of gcc during the build script. I am now also in contact with the support: The problem is that especially WindRiver Compiler are not supported in Linux, but almost any gcc compiler. They have now the preprocessed source and examine it. Also the WindRiver Support is now involved.Lenwood
Got reply from Coverity Support and we are now trying to make a workaround.Lenwood
Coverity provides now a preconfigured bundle especially for WindRiver Environments. See: windriver.com/announces/coverity-static-analysisLenwood
L
5

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.

Lenwood answered 27/1, 2012 at 9:20 Comment(0)
R
5

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.

Runyon answered 19/1, 2012 at 15:25 Comment(4)
It seems that there are a few defines discribed here: #2958898 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.Lenwood
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.Runyon
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.Lenwood
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.Runyon
L
5

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.

Lenwood answered 27/1, 2012 at 9:20 Comment(0)
Q
0

This error says it quite clearly:

inline specifier allowed on function declarations only

Is there a reason the namespace is inline? While I don't have the specification available, so I can't tell you if it's allowed or not. (That the compiler allows it may be a bug in GCC.)

Try to remove that inline and Coverity will hopefully by happy.

It seems that Coverity hasn't been updated with the some C++11 features, like inline namespaces.

Quijano answered 19/1, 2012 at 15:6 Comment(4)
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.Lenwood
inline namespaces are a C++11 feature. It's mainly for versioning a library implementation.Runyon
@Lenwood 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.Runyon
@Runyon 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.Lenwood

© 2022 - 2024 — McMap. All rights reserved.