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:
target and env set (Wind River 4 Linux)
make clean
cov-configure with compiler dir and type
cov-build with the correct "make all" command that works alone
cov-analyze
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?
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.
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.
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.
Related
I am trying to compile an application from source, FlyWithLua, which includes the sol2 library.
I am following the instructions but when I run cmake --build ./build I get the following error:
In file included from /home/jon/src/FlyWithLua/src/FloatingWindows
/FLWIntegration.cpp:10:
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp: In lambda function:
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp:7194:59:
error: ‘numeric_limits’ is not a member of ‘std’
7194 | std::size_t space = (std::numeric_limits<std::size_t>::max)();
There are several other errors on the same line after this, but I guess they might just go away if I can solve this one.
there are several similar issues with the solution to add the following includes to the .hpp file
#include <stdexcept>
#include <limits>
the sol.hpp file includes the following imports:
#include <stddef.h>
#include <limits.h>
https://sol2.readthedocs.io/en/latest/errors.html gives some hints about the why the compiler might not recognize these includes:
Compiler Errors / Warnings
A myriad of compiler errors can occur when something goes wrong. Here
is some basic advice about working with these types:
If there are a myriad of errors relating to std::index_sequence, type traits,
and other std:: members, it is likely you have not turned on your C++14 switch for
your compiler. Visual Studio 2015 turns these on by default, but g++ and clang++
do not have them as defaults and you should pass the flag --std=c++1y or
--std=c++14, or similar for your compiler.
the src/CMakeList.txt file has the following line:
set(CMAKE_CXX_STANDARD 17)
I'm only faintly familiar with C/C++ and this all seems very complicated to me, but I'm hoping that there might be an easily recognizable cause and solution to this to someone more skilled.
cat /etc/*-release gives
DISTRIB_RELEASE=21.10
DISTRIB_CODENAME=impish
DISTRIB_DESCRIPTION="Ubuntu 21.10"
$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
/home/jon/src/FlyWithLua/src/third_party/sol2/./upstream/sol.hpp:7194:59:
error: ‘numeric_limits’ is not a member of ‘std’
7194 | std::size_t space = (std::numeric_limits<std::size_t>::max)();
This error message implies that src/third_party/sol2/./upstream/sol.hpp header uses std::numeric_limits, but also that std::numeric_limits hasn't been defined. The simplest explanation for that is that the header that defines std::numeric_limits hasn't been included. In such case, the solution is to include the header that defines std::numeric_limits.
the sol.hpp file includes the following imports:
#include <stddef.h>
#include <limits.h>
This confirms the problem. Neither of those headers define std::numeric_limits.
https://sol2.readthedocs.io/en/latest/errors.html gives some hints about the why the compiler might not recognize these includes:
Those hints may apply to some other cases, but not this one. std::numeric_limits has been part of the C++ standard since the beginning, so language version has no effect on its existence.
Conclusion: According to the quoted error message, sol.hpp uses std::numeric_limits which is defined in the header <limits>, but according to you, it doesn't include that header. If this is the case, then this is a bug in the sol.hpp file. Correct solution would be to fix the sol.hpp file by including <limits> in that file before using std::numeric_limits.
I tried to compile the following sample code with clang compiler and it works fine.
Compiler Details: Apple clang version 12.0.0 (clang-1200.0.32.28)
Target: x86_64-apple-darwin20.1.0
#include <iostream>
#include <stdio.h>
int __cdecl printf(const char* format, ...)
{
std::cout<<"My printf function"<<std::endl;
return 0;
}
int main()
{
printf("Standard printf function\n");
return 0;
}
However, when I tried to compile it in visual studio 2019, it gives a compilation error.
error C2084: function 'int printf(const char *const ,...)' already has a body
What is the reason for compilation failure with MSVC?
How can I make it work, what am I missing?
My goal is to implement my version of printf() function, but wants to use other standard function available in stdio.h. How can I achieve that with MSVC?
From your code you are intentionally trying to use your own version of the printf function.
The error C2084 is expected. You are redefining something already defined. It's dangerous, and you be aware of the risks you are taking. It's a piece of a whole library and any UB (undefined Behaviour) may arise. I won't play with that. From my perspective it's g++ that is not reporting an error, but it may be that the g++/libc prototype of printf is slightly different from the one you wrote, or even, the function printf is declared in the header but not defined in there.
If you really want go down that way I strongly suggest you to define your printf in another source file and hide the libc implementation at linking time. That should be allowed (Warning and errors may arise, but every linker has an override for that).
While looking for best pratices regarding include order, I was stumbling over this thread:
C/C++ include file order/best practices [closed]
#squelart was stating, that it is better pratice to include from local to global, as this reduces the chance of hidden dependencies. I just tested this in a VS2015 project with the following code:
StrTest.h
#pragma once
class CStrTest
{
public:
CStrTest();
~CStrTest();
std::string test;
};
StrTest.cpp
#include <string>
#include "StrTest.h"
CStrTest::CStrTest()
{
}
CStrTest::~CStrTest()
{
}
I couldn't reproduce the stated behaviour (hidden dependencie duo including string first in StrTest.cpp). The compiler gives me mulitple errors. So is this something out of the past or did I overlook something?
EDIT: VS2015 Compiler errors:
Error C4430 missing type specifier - int assumed. Note: C++ does not support default-int
Error C2039 'string': is not a member of 'std'
Error C3646 'test': unknown override specifier
So is this something out of the past
No, the hidden dependencies are the standard behaviour and do happen in modern compilers. I don't know of VS, but GCC and Clang do compile your shown program without any errors. Demo: https://wandbox.org/permlink/ATJndwrOwirpDgDd
The compiler gives me mulitple errors.
Although an "implicit" include is poor style, it is still technically well formed as far as the standard is concerned as long as the implicitly included file is guaranteed to be included by you or whoever wrote the header that includes it - standard headers have no such guarantees.
Therefore I would be against such compiler feature that considers implicit includes as errors. An explicitly enable-able warning would be much more suitable.
I think the point of hidden dependence problem discussed there is that typically each file includes several other files and if header is not self-contained then including it may work in cases when it's implicit dependences are included by some other header and break everything when those other headers change and / or get moved / removed. In short: use of headers with hidden dependencies lead to extremely fragile code.
// foo.hpp
#pragma once
#include <string> // if we remove this unrelated `StrTest.h` header will be broken
...
.
// main.cpp
#include "foo.hpp" // if we move this one line lower `StrTest.h` header will be broken
#include "StrTest.h" // accidentally works fine
...
I am now trying to build a c++ library in linux with cmake. If I do not enable -std=c++0x option, I always get compilation errors error: 'div_t' was not declared in this scope for the following codes:
int xPos;
div_t divResult;
divResult = div(xPos,8);
Then if I enable -std-c++0x options with cmake: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x", then everything is fine. However, in my library I did not use any c++0x features, so I am reluctant to set std=c++0x option. So I search the head file that defines div_t and find it is defined in stdlib.h within the following MACRO:
__BEGIN_NAMESPACE_STD
typedef struct
{
int quot;
int rem;
} div_t;
....
....
__END_NAMESPACE_STD
It seems to me that if I can enable these macros I can build the library without enabling c++0x feature. So my question is what I can do in this situation.
By the way, I can build the library very well without enabling c++0x feature if only g++4.4 is installed in the linux machine. When I also install g++4.6 and make g++4.6 the default g++, then the compilation error began to occur. Even I changed the default g++ to g++4.4, the compilation error still exists if I do not enable c++0x feature.
The macros expand to namespace std { and } respectively if the code is pulled in through a C++ standard library header. This leads me to believe that you're not #including stdlib.h directly (which is good!).
Earlier versions of libstdc++ pulled symbols from C legacy headers into the global namespace even if the C++ versions of these headers (e.g. <cstdlib> instead of <stdlib.h>) were used; newer ones place them only in namespace std.
The cleanest way to fix this is to
#include <cstdlib>
in all translation units where the problem occurs and to use std::div instead of div. If you're lazy, you can also
#include <stdlib.h>
in all translation units that use div, but mixing C and C++ is always icky. Not terribad in this particular case, though.
I have a project that correctly compiles and runs under g++ 4.8.1 and clang >= 3.3 in c++11 mode. However, when I switch to the experimental -std=c++1y mode, clang 3.3 (but not g++) chokes on the <cstdio> header that is indirectly included by way of Boost.Test (so I cannot easily change it myself)
// /usr/include/c++/4.8/cstdio
#include <stdio.h>
// Get rid of those macros defined in <stdio.h> in lieu of real functions.
// ...
#undef gets
// ...
namespace std
{
// ...
using ::gets; // <-- error with clang++ -std=c++1y
// ...
}
with the following error message:
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/cstdio:119:11:
error: no member named 'gets' in the global namespace
On this tutorial on how to set up a modern C++ environment, a similar lookup problem with max_align_t is encountered. The recommendation there is to use a sed script to surround the unknown symbols with #ifdef __clang__ macros, but that seems a fragile approach.
Setup: plain 64-bit Linux Mint 15 with
g++ (Ubuntu 4.8.1-2ubuntu1~13.04) 4.8.1
Ubuntu clang version 3.3-3~raring1 (branches/release_33) (based on
LLVM 3.3)
Questions:
what is causing this erorr? There is no __clang__ macro anywhere near the code in question, and clang in c++11 mode has no trouble at all.
Is it a language problem (does C++14 say something else than C++11 about importing C compatible symbols from the global into the std namespace)?
Do I need to change something with my include paths? (I use CMake to automatically select the header paths, and switch modes inside CMakeLists.txt)
Does clang have a switch to resolve this?
This note in the gets manpage looks relevant:
ISO C11 removes the specification of gets() from the C language, and since version 2.16, glibc header files don't expose the function declaration if the _ISOC11_SOURCE feature test macro is defined.
Probably should be
#if !_ISOC11_SOURCE
using ::gets;
#endif