So I've recently begun using flycheck within emacs. Overall it's working great, but I've been having a small issue with flycheck using cppcheck in c++ mode. I'm getting a bunch of unusedStructMember warnings, likely due to not using that member within the present file. I was wondering if it is possible to tell flycheck to disable the unusedStructMember warnings from cppcheck, and if so, how would I go about doing so? My emacs-lisp skills are mostly non-existent and so far I haven't found anyone with a similar problem.
Thanks!
This is not an emacs configuration but something depends on the backend you use for C++ flycheck (i.e. cppcheck).
I just took a look at the manual of cppcheck. Obviously you can do it by inline pragmas. For example:
void f() {
char arr[5];
// cppcheck-suppress arrayIndexOutOfBounds
arr[10] = 0;
}
In your case, you'll need something like:
// cppcheck-suppress unusedStructMember
Related
I am running static code analysis using cppcheck.
I have a cpp source file which as bugs like "null pointer dereferenced" etc.
There is a piece of code in file. A structure is declared inside a class
class Example{
public:
typedef struct {
int num;
}MyStruct;
};
When array of structure is declared
Example::MyStruct st_arr[5];
Cppcheck stops the analysis as soon as it reaches this code and doesn't go further and report other bugs in file.
But if I simply declare a struct variable
Example::MyStruct st;
It goes fine.
So, the cppcheck stops the analysis when array of struct (declared in a class) is created.
Is this a issue with cppcheck?
I am a Cppcheck developer.
I see such weird behaviour also. It is not by intention. I will investigate.
Best regards,
Daniel Marjamäki
Most static analysis tools can be configured to not report errors from library headers. You probably have to configure cppcheck to recognize the headers, e.g. by defining paths which are treated as library files. They also usually parse special comments in the source code which can be used to suppress errors in regions of code, e.g. suppress errors before the include and then re-enable afterwards. How this works is described in the documentation of the tools.
These tools also have the ability to define suppressions to discard errors, e.g. false positives. This can also be used to suppress errors from third-party code.
The cppcheck manual chapters "Chapter 8. Suppressions" and "Chapter 9. Library configuration" should explain how to do this. If you have specific problems with the configuration you can post more detailed questions.
I'm seeing something weird happening with Visual Studio 2015 Community. Code that worked perfectly in VS2012 crashes at startup when ported to VS2015, before main is invoked: the classic symptoms of some static initialization mess. I have a few static variables, but used properly, with the standard "Construct On First Use" pattern, e.g.:
const int& i()
{
static int *v = new int(1);
return *v;
}
The code above causes an assert from the runtime while initializing the program (see image http://i.stack.imgur.com/nsQGS.png). Pressing retry simply quits the program: no call stack, no information whatsoever.
The code below however works flawlessly:
const int& i()
{
static int *v = nullptr;
if (v == nullptr)
v = new int(1);
return *v;
}
It seems to me that VS2015 is doing what looks like some (illegal) optimization (even in a debug build), by executing the static variable initialization code during program initialization, and not the first time that the function is called, as the C++ standard requires.
I tried several variations of the code above: class methods, free functions, different objects (std::vector, cv::Mat), always with the same result: the static pointer has to be initialized to null or the program doesn't start.
So... am I missing something or is VS2015 actually messing up badly?
UPDATE:
I spent some time trying to find the minimal setup that shows the problem, and this is what I got:
create a project using the "CLR empty project" template.
add a cpp file, containing just the offending function and main(). Main can be empty, it doesn't matter: the bug occurs BEFORE it is even reached.
add 'main' as entry point (or you get a link error).
The x86 version works, but the x64 doesn't.
For comparison, a project with the identical code but created as "Win32 console application" doesn't have the problem, even after adding the /CLR option. I can see differences in the vcxproj files, but none justifies the error, although one or more of them clearly IS the cause.
Is there a way to upload a zip with the project?
Well, #bogdan got it right. My project had a mix of settings that was neither /SUBSYSTEM:CONSOLE nor /SUBSYSTEM:WINDOWS. Once I fixed that, everything started to work as expected. My test projects had the same problem, I blame Microsoft for not having a clear "CLR windows app" C++ template any more in VS2015 (they want to push you to use C# for that, which makes sense most of the times, but not always).
I found this page particularly useful in explaining all the different settings that have to be consistent (it's not just /SUBSYSTEM...).
I wish I could mark #bogdan's comment as answer, but I can't see anything to do that.
Thanks Bogdan!
Iv been trying to figure this one out forever, and its starting to annoy me. I understand the D runtime library. What it is, what it does. I also understand that you can compile a D app without it. Like what XoMB does. Well, XoMB defines its own runtime, but there are cases where you dont need to write your own, if you dont need it. I understand that the DigitalMars D compiler (dmd) which is what im using, does alot of things behind the scenes for the runtime, like emiting references to certain things depending on whats needed by your program. And also, things for EVERY program. So you must define these yourself. i decided to experiment, try to figure it out myself and got pretty far. By that i mean getting the linker to spit out less and less errors. For a test i just want to compile a complete bare-bones
app, simply to get things working without the runtime. Or as little of runtime as possible. here is what i have my single source file.
module main;
void _main()
{
int a = 2 + 3;
}
I compile with: dmd -c main.d -defaultlib=
Then link with: link main.obj
And this is the errors i get: OPTLINK : Warning 23: No Stack & OPTLINK: Warning 134: No Start Address
You can see i tried chaingng main to _main to get rid of the no start address error but,
anyway, didnt help. What do i need to do to iron out these last two errors? if i can get it working, i think i can look up what i need to implement to get more features working. But if anyone is willing to to help me out with that, it would be much apreciated!
module main;
extern(C) __gshared void* _Dmodule_ref;
extern(C) int main() {
int a = 2 + 3;
return 0;
}
ldc -nodefaultlib -noruntime
I've had success with that. But you'll still want to add:
extern(C) __gshared void* _Dmodule_ref;
extern(C) int main() {}
Note that while the runtime is optional, it is required for a lot of the features. You'll be missing array slicing, (dynamic arrays?), GC, and plenty of others. If you accidentally use one of those features, you'll get plenty of warnings about how it can't find some obscure symbol name.
Will the compiler remove this if statement?
#define DEBUG 0
int main(int argc, char ** argv)
{
if(DEBUG)
{
...
}
return 0;
}
I tried to google this, and search stackoverflow but I think my search terms were bad because I couldn't find the information.
If this is optimized what would I want to read about to learn about the optimization?
Constantin
Yes, any decent C/C++ compiler will remove such if block.
I'm not sure if a compiler can optimize it away. I guess yes since in this situation you couldn't have any side effect, so it can be safely removed without changing semantics of the code.
In any case guessing is not nice and relying on an optimization is not nice too.
Why don't you use a #ifdef .. #endif block instead that a code block?
#define DEBUG
#ifdef DEBUG
...
#endif
In this way you will have a sure outcome.
You don't need to guess. Compile and step with debugger watching assembly instructions. You don't even need to be well familiar with assembly to see if there is actual code generated for lines in question or not.
You cannot make the universal statement that every compiler will optimize the same things the same way. Likewise any compiler that might happen to do it today might not in some future version.
Yes, a number of compilers today can and will do that but that doesnt mean you should plan for it or expect it. If you dont want that code there, comment it out, ifdef it out or remove it.
As mentioned by others, try it and find out for yourself. If you are debugging something and suspect that this has or has not happened, simply look and find out...
You got good answers to check it in your compiler assembly output. I would like to share similar idiom that is very usefull to me sometimes:
int main(int argc, char ** argv)
{
const bool bDebug = false;
if(bDebug)
{
...
LOG(""); /// some heavy loging here
}
return 0;
}
so I leave such if-s in some relevant places in my code, and when I get a bug report that something bad happend I step through code and when I need to ouput some large arrays/data structures, I modify from debugger bDebug variable (actually I name them bVerbose), and then allow code to enter such IF-s. You dont have to recompile code to add heavy logging.
General Question which may be of interest to others:
I ran into a, what I believe, C++-compiler optimization (Visual Studio 2005) problem with a switch statement. What I'd want to know is if there is any way to satisfy my curiosity and find out what the compiler is trying to but failing to do. Is there any log I can spend some time (probably too much time) deciphering?
My specific problem for those curious enough to continue reading - I'd like to hear your thoughts on why I get problems in this specific case.
I've got a tiny program with about 500 lines of code containing a switch statement. Some of its cases contain some assignment of pointers.
double *ptx, *pty, *ptz;
double **ppt = new double*[3];
//some code initializing etc ptx, pty and ptz
ppt[0]=ptx;
ppt[1]=pty; //<----- this statement causes problems
ppt[2]=ptz;
The middle statement seems to hang the compiler. The compilation never ends. OK, I didn't wait for longer than it took to walk down the hall, talk to some people, get a cup of coffee and return to my desk, but this is a tiny program which usually compiles in less than a second. Remove a single line (the one indicated in the code above) and the problem goes away, as it also does when removing the optimization (on the whole program or using #pragma on the function).
Why does this middle line cause a problem? The compilers optimizer doesn't like pty.
There is no difference in the vectors ptx, pty, and ptz in the program. Everything I do to pty I do to ptx and ptz. I tried swapping their positions in ppt, but pty was still the line causing a problem.
I'm asking about this because I'm curious about what is happening. The code is rewritten and is working fine.
Edit:
Almost two weeks later, I check out the closest version to the code I described above and I can't edit it back to make it crash. This is really annoying, embarrassing and irritating. I'll give it another try, but if I don't get it breaking anytime soon I guess this part of the question is obsolete and I'll remove it. Really sorry for taking your time.
If you need to make this code compilable without changing it too much consider using memcpy where you assign a value to ppt[1]. This should at least compile fine.
However, you problem seems more like another part of the source code causes this behaviour.
What you can also try is to put this stuff:
ppt[0]=ptx;
ppt[1]=pty; //<----- this statement causes problems
ppt[2]=ptz;
in another function.
This should also help compiler a bit to avoid the path it is taking to compile your code.
Did you try renaming pty to something else (i.e. pt_y)? I encountered a couple of times (i.e. with a variable "rect2") the problem that some names seem to be "reserved".
It sounds like a compiler bug. Have you tried re-ordering the lines? e.g.,
ppt[1]=pty;
ppt[0]=ptx;
ppt[2]=ptz;
Also what happens if you juggle about the values that are assigned (which will introduce bugs in your code, but may indicator whether its the pointer or the array that's the issue), e.g.:
ppt[0] = pty;
ppt[1] = ptz;
ppt[2] = ptx;
(or similar).
It's probably due to your declaration of ptx, pty and ptz with them being optimised out to use the same address. Then this action is causing your compiler problems later in your code.
Try
static double *ptx;
static double *pty;
static double *ptz;