c++ - compiler - visual studio treat warnings as errors




Why should I always enable compiler warnings? (9)

I often hear that when compiling C and C++ programs I should "always enable compiler warnings". Why is this necessary? How do I do that?

Sometimes I also hear that I should "treat warnings as errors". Should I? How do I do that?


Why enable warnings?

C and C++ compilers are notoriously bad at reporting some common programmer mistakes by default , such as:

  • forgetting to initialise a variable
  • forgetting to return a value from a function
  • arguments in printf and scanf families not matching the format string
  • a function is used without being declared beforehand (C only)

These can be detected and reported, just usually not by default; this feature must be explicitly requested via compiler options.

How to enable warnings?

This depends on your compiler.

Microsoft C and C++ compilers understand switches like /W1 , /W2 , /W3 , /W4 and /Wall . Use at least /W3 . /W4 and /Wall may emit spurious warnings for system header files, but if your project compiles cleanly with one of these options, go for it. These options are mutually exclusive.

Most other compilers understand options like -Wall , -Wpedantic and -Wextra . -Wall is essential and all the rest are recommended (note that, despite its name, -Wall only enables the most important warnings, not all of them). These options can be used separately or all together.

Your IDE may have a way to enable these from the user interface.

Why treat warnings as errors? They are just warnings!

A compiler warning signals a potentially serious problem in your code. The problems listed above are almost always fatal; others may or may not be, but you want compilation to fail even if it turns out to be a false alarm. Investigate each warning, find the root cause, and fix it. In the case of a false alarm, work around it — that is, use a different language feature or construct so that the warning is no longer triggered. If this proves to be very hard, disable that particular warning on a case by case basis.

You don't want to just leave warnings as warnings even if all of them are false alarms. It could be OK for very small projects where the total number of warnings emitted is less than 7. Anything more, and it's easy for a new warning to get lost in a flood of old familiar ones. Don't allow that. Just cause all your project to compile cleanly.

Note this applies to program development. If you are releasing your project to the world in the source form, then it might be a good idea not to supply -Werror or equivalent in your released build script. People might try to build your project with a different version of the compiler, or with a different compiler altogether, which may have a different set of warnings enabled. You may want their build to succeed. It is still a good idea to keep the warnings enabled, so that people who see warning messages could send you bug reports or patches.

How to treat warnings as errors?

This is again done with compiler switches. /WX is for Microsoft, most others use -Werror . In either case, the compilation will fail if there are any warnings produced.


Non-fixed warnings will , sooner or later, lead to errors in your code .

Debugging a segmentation fault, for instance, requires the programmer to trace the root (cause) of the fault, which usually is located in a prior place in your code than the line that eventually caused the segmentation fault.

It's very typical that the cause is a line for which the compiler had issued a warning that you ignored, and the line that caused the segmentation fault the line that eventually threw the error.

Fixing the warning leads to fixing the problem.. A classic!

A demonstration of the above.. Consider the following code:

#include <stdio.h>

int main(void) {
  char* str = "Hello world!";
  int idx;

  // Colossal amount of code here, irrelevant to 'idx'

  printf("%c\n", str[idx]);

  return 0;
}

which when compiled with "Wextra" flag passed to GCC, gives:

main.c: In function 'main':
main.c:9:21: warning: 'idx' is used uninitialized in this function [-Wuninitialized]
    9 |   printf("%c\n", str[idx]);
      |                     ^

which I could ignore and execute the code anyway.. And then I would witness a "grand" segmentation fault, as my IP epicurus professor used to say:

Segmentation fault

In order to debug this in a real world scenario, one would start from the line that causes the segmentation fault and attempt to trace what is the root of the cause.. They would have to search for what has happened to i and str inside that colossal amount of code over there...

Until, one day, they found theirselves in the situation where the discover that i is used uninitialized, thus it has a garbage value, which results in indexing the string (way) beyond out of its bounds, which leads to a segmentation fault.

If only they hadn't ignored the warning, they would have found the bug immediately!


C is, famously, a rather low-level language as HLLs go. C++, though it might seem to be a considerably higher-level language than C, still shares a number of its traits. And one of those traits is that the languages were designed by programmers, for programmers -- and, specifically, programmers who knew what they were doing.

[For the rest of this answer I'm going to focus on C. Most of what I'll say also applies to C++, though perhaps not as strongly. Although as Bjarne Stroustrup has famously said, "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." ]

If you know what you are doing -- really know what you are doing -- sometimes you may have to "break the rules". But most of the time, most of us will agree that well-intentioned rules keep us all out of trouble, and that wantonly breaking those rules all the time is a bad idea.

But in C and C++, there are surprisingly large numbers of things you can do that are "bad ideas" but which aren't formally "against the rules". Sometimes they're a bad idea some of the time (but might be defensible other times); sometimes they're a bad idea virtually all of the time. But the tradition has always been not to warn about these things -- because, again, the assumption is that programmers know what they are doing, they wouldn't be doing these things without a good reason, they'd be annoyed by a bunch of unnecessary warnings.

But of course not all programmers really know what they're doing. And, in particular, every C programmer (no matter how experienced) goes through a phase of being a beginning C programmer. And even experienced C programmers can get careless and make mistakes.

Finally, experience has shown not only that programmers do make mistakes, but that these mistakes can have real, serious consequences. If you make a mistake, and the compiler doesn't warn you about it, and somehow the program doesn't immediately crash or do something obviously wrong because of it, the mistake can lurk there, hidden, sometimes for years, until it causes a really big problem.

So it turns out that, most of the time, warnings are a good idea, after all. Even the experienced programmers have learned (actually, it's " especially the experienced programmers have learned") that, on balance, the warnings tend to do more good than harm. For every time you did something wrong deliberately and the warning was a nuisance, there are probably at least ten times you did something wrong by accident and the warning saved you from further trouble. And most warnings can be disabled or worked around for those few times when you really want to do the "wrong" thing.

(A classic example of such a "mistake" is the test if(a = b) . Most of the time, this is a mistake, so most compilers these days warn about it -- some even by default. But if you really wanted to both assign b to a and test the result, you can disable the warning by typing if((a = b)) .)

The second question is, why would you want to ask the compiler to treat warnings as errors? I'd say it's because of human nature, specifically, the all-too-easy reaction of saying "Oh, that's just a warning, that's not so important, I'll clean that up later." But if you're a procrastinator (and I don't know about you, but I'm a terrible procrastinator) it's easy to put off the necessarily cleanup for basically ever -- and if you get into the habit of ignoring warnings, it gets easier and easier to miss an important warning message that's sitting there, unnoticed, in the midst of all the ones you're ignoring.

So asking the compiler to treat warnings as errors is a little trick you can play on yourself to get around this human foible.

Personally, I'm not as insistent about treating warnings as errors. (In fact, if I'm honest, I can say that I virtually never enable that options in my "personal" programming.) But you can be sure I've got that option enabled at work, where our style guide (which I wrote) mandates its use. And I would say -- I suspect most professional programmers would say -- that any shop that doesn't treat warnings as errors in C is behaving irresponsibly, is not adhering to commonly-accepted industry best practices.


Not only does handling the warnings make better code, it makes you a better programmer. Warnings will tell you about things that may seem little to you today, but one day that bad habit will come back and bite your head off.

Use the correct type, return that value, evaluate that return value. Take time and reflect "Is this really the correct type in this context?" "Do I need to return this?" And the biggie; "Is this code going to be portable for the next 10 years?"

Get into the habit of writing warning-free code in the first place.


Take it easy: you don't have to, it is not necessary. -Wall and -Werror was designed by code-refactoring maniacs for themselves: it was invented by compiler developers to avoid breaking existing builds after compiler update on the user side . Later, people who hates when others brake their code also found it useful. The feature is nothing, but all about decision to break or not to break the build.

So, it is totally up to your preference to use or not. I use it all the time because it helps to fix my mistakes.


The compiler warnings in C++ is very useful for some reasons.

1 - It permit to show you where you can have made a mistake who can impact the final result of your operations. For example if you didn't initialize a variable or if you put "=" instead of "==" ( there are just examples )

2 - It permits also to show you where your code is not conform to the standard of the c++. It's useful because if the code is conform to the actual standard it will be easy to move the code into an other plateform for example.

In general, the warnings are very useful to show you where you have mistakes in your code who can affect the result of your algorithm or prevent some error when the user will use your program.


This is a specific answer to C, and why this is far more important to C than to anything else.

#include <stdio.h>
int main()
{
   FILE *fp = "some string";
}

This code compiles with a warning . What are and should be errors in just about every other language on the planet (barring assembly language) are warnings in C. Warnings in C are almost always errors in disguise. Warnings should be fixed, not suppressed.

With gcc , we do this as gcc -Wall -Werror .

This was also the reason for the high rantyness about some MS non-secure API warnings. Most people programming C have learned the hard way to treat warnings as errors and this stuff appeared that just wasn't the same kind of thing and wanted non-portable fixes.


Treating warnings as errors is just a mean of self-discipline: you were compiling a program to test that shiny new feature, but you can't until you fix the sloppy parts. There is no additional information Werror provides, it just sets priorities very clearly:

Don't add new code until you fix problems in the existing code

It's really the mindset that's important, not the tools. Compiler diagnostics output is a tool. MISRA (for embedded C) is another tool. It doesn't matter which one you use, but arguably compiler warnings is the easiest tool you can get (it's just one flag to set) and the signal to noise ratio is very high. So there's no reason not to use it.

No tool is infallible. If you write const float pi = 3.14; , no tool will tell you that you defined π with a bad precision which may lead to problems down the road. Most tools won't raise an eyebrow on if(tmp < 42) , even if it's commonly known that giving variables meaningless names and using magic numbers is a way to disaster in big projects. You have to understand that any "quick test" code you write is just that: a test, and you have to get it right before you move on to other tasks, while you still see its shortcomings. If you leave that codes as is, debugging if after you spend two months adding new features will be significantly harder.

Once you get into the right mindset, there is no point in using Werror . Having warnings as warnings will allow you to take an informed decision whether it still makes sense to run that debug session you were about to start, or to abort it and fix the warnings first.


You should always enable compiler warnings because the compiler can often tell you what's wrong with your code. To do this, you pass -Wall -Wextra to the compiler.

You should usually treat warnings as errors because often the warnings usually signify that there's something wrong with your code. However, it's often very easy to ignore these errors. Therefore, treating them as errors will cause the build to fail so you can't ignore the errors. To treat warnings as errors, pass -Werror to the compiler.





compiler-warnings