Best compiler warning level for C/C++ compilers?

Question

What compiler warning level do you recommend for different C/C++ compilers?

gcc and g++ will let you get away with a lot on the default level. I find the best warning level for me is '-Wall'. And I always try to remove fix the code for the warnings it generates. (Even the silly ones about using parenthesis for logical precedence rules or to say I really mean 'if (x = y)')

What are your favorite levels for the different compilers, such as Sun CC, aCC (HPUX ?), Visual Studio, intel?

Edit:

I just wanted to point out that I don't use "-Werror" (but I do understand it's utility) on gcc/g++ because, I use:

#warning "this is a note to myself"

in a few places in my code. Do all the compilers understand the #warning macro?

Answer 1

I tend to use -Wall (because everyone does make bugs, nobody is perfect) , but i don't use -Werror (treat warnings as errors) because now and then gcc warns about things which are right anyway (false positives).

Answer 2

On Visual C++, I use /W4 and /WX (treat warnings as errors).

VC also has /Wall, but it's incompatible with the standard headers.

I choose to treat warnings as errors, because that forces me to fix them. I fix all warnings, even if that means adding #pragma to ignore the warning - that way, I'm stating explicitly, that I'm aware of the warning (so other developers won't e-mail me about it).

Answer 3

I agree with litb to always use -Wall. In addition, if you want to ensure your code is compliant you can also use -pedantic. Another warning that can be helpful if you're handling unions and structs at the byte level is -Wpadded.

Answer 4

In Visual C I use /w3. I find w4 throws up too much noise (lots of it from the MS libraries) to go through on every build. The extra warnings are very minor and haven't been a cause of a bug so far.

Answer 5

I believe VC also supports

#pragma message ("note to self")

But as the system grows and grows, and you get a nightly build 30 developers work on simultaneously, it takes days to read all the notes to self, even in that amount that self is going to be do nothing but note reading and finally going to break under the stress not being able to keep up and have to resign...

No really, the amount of warnings is quickly going to grow if you allow them, and you won't be able to spot the really important ones (uninitialized variables, this pointer used in constructor, ...).

That's why I try to treat warnings as errors: most of the time, the compiler is right warning me, and if he isn't, I document it in the code and prepend

#pragma warning ( push )
#pragma warning ( 4191 : disable )
// violent code, properly documented
#pragma warning ( pop )

I just read they have a warning ( N : suppress ) pragma, too.

Answer 6

I do all development with Warning as Errors turned on.

Since I still develop in VC6 I have a lot of #pragma's in my code (4786 mainly).

Answer 7

I like -Wall and strict prototypes as well as implicit function definitions. Errors on those can be very useful.

On Unix-like systems you have to obey the user's ENV preferences .. so what they see and report might be entirely different than what you need :)

I'm also a type punning fiend, so I tend to set -Fno-strict-aliasing as well, unless the user wants it. Safe memory management in classic C is hard to accomplish otherwise.

Answer 8

There's a nice list of options for GCC here: http://mces.blogspot.com/2008/12/year-end-cleaning-ie-on-warning-options.htm. -Wall does not enable all the possible warnings, and some have to be enabled explicitely.

Answer 9

Thanks everyone for their answers. It has been a while since I've used anything but gcc/g++. Ones I've had to use a long time ago are

-fmessage-length = 0 (since g++ had an ugly habit of line breaking messages)

-Wno-deprecated      (since I worked on a code base pre-existing the std namespace)

I do remember that (at least 5 years ago) anything above the default warning level on the Sun Workshop CC compiler was too much. I also think this may have been true for the Intel compiler. I have not been up to date with non gnu compilers for a while.

Answer 10

This is a set of extra-paranoid flags I'm using for C++ code:

    -g -O -Wall -Weffc++ -pedantic  \
    -pedantic-errors -Wextra  -Wall -Waggregate-return -Wcast-align \
    -Wcast-qual  -Wchar-subscripts  -Wcomment -Wconversion \
    -Wdisabled-optimization \
    -Werror -Wfloat-equal  -Wformat  -Wformat=2 \
    -Wformat-nonliteral -Wformat-security  \
    -Wformat-y2k \
    -Wimplicit  -Wimport  -Winit-self  -Winline \
    -Winvalid-pch   \
    -Wunsafe-loop-optimizations  -Wlong-long -Wmissing-braces \
    -Wmissing-field-initializers -Wmissing-format-attribute   \
    -Wmissing-include-dirs -Wmissing-noreturn \
    -Wpacked  -Wpadded -Wparentheses  -Wpointer-arith \
    -Wredundant-decls -Wreturn-type \
    -Wsequence-point  -Wshadow -Wsign-compare  -Wstack-protector \
    -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch  -Wswitch-default \
    -Wswitch-enum -Wtrigraphs  -Wuninitialized \
    -Wunknown-pragmas  -Wunreachable-code -Wunused \
    -Wunused-function  -Wunused-label  -Wunused-parameter \
    -Wunused-value  -Wunused-variable  -Wvariadic-macros \
    -Wvolatile-register-var  -Wwrite-strings

That should give you something to get started. Depending on a project, you might need to tone it down in order to not see warning coming from third-party libraries (which are usually pretty careless about being warning free.) For example, Boost vector/matrix code will make g++ emit a lot of noise.

A better way to handle such cases is to write a wrapper around g++ that still uses warnings tuned up to max but allows one to suppress them from being seen for specific files/line numbers. I wrote such a tool long time ago and will release it once I have time to clean it up.

Answer 11

The GCC compilers become stricter with every new version. Use the flag -ansi to produce warnings for violations of the strictest interpretation of the ANSI language standards. That's usually stuff that just happens to work in your current compiler, but may produce errors in the next version or in other compilers. That flag will help you avoid having to port your code every time you switch compilers/versions.

Answer 12

On GCC, for preference I use "-Wall -Wextra -Wwrite-strings -Werror", and also specify a standard with std=. Which standard depends on the project: principally on how portable it needs to be.

The reason I use -Werror is that warnings are unacceptable (to me) even if they don't represent a real bug. I'd rather work around whatever caused the warning, than have to ignore warnings every single time I compile for the rest of my life. Once you allow warnings in the compile, it's just too easy to miss one that wasn't there last time.

Of course when dealing with third-party code, sometimes you can't get rid of the warnings. Then I'd decide on a case-by-case basis whether to relax the -W options, remove -Werror and write a script to check that only expect warnings occur, or maybe modify the third-party code (either to "fix" the warning or to disable it with pragmas if possible).