Why should I always enable compiler warnings?

Question

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 tha

Answer 1

Warnings consist of the best advice some of the most skilled C++ developers could bake into an application. They're worth keeping around.

C++, being a Turing complete language, has plenty of cases where the compiler must simply trust that you knew what you are doing. However, there are many cases where the compiler can realize that you probably did not intend to write what you wrote. A classic example is printf() codes which don't match the arguments, or std::strings passed to printf (not that that ever happens to me!). In these cases, the code you wrote is not an error. It is a valid C++ expression with a valid interpretation for the compiler to act on. But the compiler has a strong hunch that you simply overlooked something which is easy for a modern compiler to detect. These are warnings. They are things that are obvious to a compiler, using all the strict rules of C++ at its disposal, that you might have overlooked.

Turning warnings off, or ignoring them, is like choosing to ignore free advice from those more skilled than you. Its a lesson in huberis that ends either when you fly too close to the sun and your wings melt, or a memory corruption error occurs. Between the two, I'll take falling from the sky any day!

"Treat warnings as errors" is the extreme version of this philosophy. The idea here is that you resolve every warning the compiler gives you -- you listen to every bit of free advice and act on it. Whether this is a good model for development for you depends on the team and what kind of product you are working on. It's the ascetic approach that a monk might have. For some, it works great. For others, it does not.

On many of my applications we do not treat warnings as errors. We do this because these particular applications need to compile on several platforms with several compilers of varying ages. Sometimes we find it is actually impossible to fix a warning on one side without it turning into a warning on another platform. So we are merely careful. We respect warnings, but we don't bend over backwards for them.

Answer 2

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.

Answer 3

A warning is an error waiting to happen. So you must enable compiler warnings and tidy up your code to remove any warning.

Answer 4

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 or programming language updates on the user side. The feature is nothing, but all about the decision to break or not to break the build.

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

Answer 5

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.

Answer 6

The fact that C++ compilers accept compiling code that obviously results in undefined behavior at all is a major flaw in the compilers. The reason they don't fix this is because doing so would probably break some usable builds.

Most of the warnings should be fatal errors that prevent the build from completing. The defaults to just display errors and do the build anyway are wrong and if you don't override them to treat warnings as errors and leave some warnings then you will likely end up with your program crashing and doing random things.