| Version 12 (modified by , 12 years ago) ( diff ) |
|---|
Managing Warnings from Compilers (and other tools)
Avoid warnings, Eliminate warning, Suppress Warnings, or Document.
Boost aims to avoid warnings messages as far as is reasonably practicable, even when compiled with the highest and most pedantic warning level, avoiding vendor specific extensions if possible.
Warnings often indicate real problems. Sometimes they only manifest on a particular platform, revealing a portability issue. Sometimes they indicate that the code doesn't account for a runtime condition, like overflow, which the warning can only suggest as a possibility.
Suppressing a warning without altering code may simply mask a problem. The right approach is to determine why the warning occurs, to decide whether it is correct in the context, and if so, apply appropriate remediation. If the warning is not correct in the context, only then should it be suppressed.
Because developers don't have the same knowledge, even among Boost developers, Boost is amassing information to help them know when a warning is significant and not. That information can show cases in which a warning is legitimate and when it isn't. For the former, there is help to understand how to change the code portably to account for the problem revealed by the warning. For the latter, there is information on how to suppress the warning in a portable way.
Changing code can lead to bugs. Thus, changing code to eliminate a warning might create a bug. That's unfortunate. From a maintenance standpoint, however, most would prefer to see altered code to a glob of preprocessor and pragma line noise that suppresses a warning in the unchanged code.
Testing will reveal the bug. If it doesn't, the testing is insufficient. If the bug appears on an untested platform, then more testers are needed to be able to detect such bugs in the future.
Briefly, for some users, any warning is a bug.
See also https://svn.boost.org/trac/boost/wiki/WarningFixes for progress made on warning fixes/suppression in Boost libraries.
Reasons to eliminate or suppress warnings:
1 To allow users, whose environment requires no warnings, to use Boost code.
2 To avoid the nuisance, perhaps overwhelming, of spurious warning messages.
3 To improve code quality by focusing library writers' attention on potential problems.
4 To improve portability by focusing developer attention on potentially non-portable code.
5 To improve compliance with the C++ Standard.
6 To permit users to set high warning levels when using Boost libraries without being overwhelmed with a barrage of library warnings.
7 To document that warnings have been considered by the library author or maintainer and are considered not significant.
8 For Boost, making the suppression local is more important than only suppressing a specific warning.
What to do
1 Test compilation with the most pedantic setting for the compiler, and non-debug mode.
For Microsoft Visual Studio, this means setting level to 4 (command line /W4).
You might also try compiling with the /Za option to disable MS extensions, but this may not be as useful as one might hope for reasons explained by Stephan T. Lavavej from the Microsoft STL team in an authoritative post at http://article.gmane.org/gmane.comp.lib.boost.devel/212186/ /Za and Warning Guidelines for VC.
Briefly, there are several problems. Firstly, the latest compilers, especially VC10, is "pretty conformant" and so code is likely to be portable anyway. Secondly, there is a bug which means that valid code fails to compile, and this is not expected to be fixed for some time. Thirdly, is the possible need to link to other libraries, for example regex, that also must be built with the /Za option. But there is no way to distinguish libraries built with and without this option by filename, so that they cannot co-exist: this is a recipe for trouble!
The ultimate test of C++ code portability is still testing on as wide a variety of platforms as possible.
Having said that, if you only have access to a Microsoft platform, before launching code on the full array of testers, you might consider checking if any indications of non-portability emerge from testing with language extensions disabled.
To do this, (for code that doesn't deliberately use Microsoft language extensions), use the VS IDE to disable them with Disable MS extensions = Yes, which adds command line option /Za
To a jamfile add <toolset>msvc:<cxxflags>/Za # disable MS extensions.
If it proves impossible to compile with the /Za option (it causes trouble with some MS compilers, sometimes), just document this, including a comment in the build jamfile.
If only one (or a few) modules in a test (or other) build require MS extensions, you can selectively 'switch off' this 'disable' in the 'requirements' in the jamfile, for example:
# pow test requires type_of that MS extensions.
run pow_test.cpp ../../test/build//boost_test_exec_monitor
: # command line
: # input files
: # requirements
-<toolset>msvc:<cxxflags>/Za # Requires type_of which requires MS extensions, so cancel /Za.
: test_pow
;
Note the leading - switches off the compiler switch /Za, producing output thus:
compile-c-c++ ..\..\..\bin.v2\libs\math\test\test_pow.test\msvc-9.0\debug\asynch-exceptions-on\threading-multi\pow_test.obj
pow_test.cpp
using native typeof
(You might also consider using Microsoft /Wall if available. You may find
http://www.geoffchappell.com/viewer.htm?doc=studies/msvc/cl/c1xx/warnings/index.htm&tx=2,27&ts=0,3820
a helpful guide to the byzantine complexity of warnings).
(If you really wish to make all of your VS projects in all VS solutions compile with other options by default, you might consider (carefully) editing (with a text editor, very carefully, after keeping a copy of the original) the file C:\Program Files\Microsoft Visual Studio 9.0\VC\VCWizards\1033\common.js to change from the Microsoft defaults. This does not seem to be officially documented as far as I know. It may save you changing the project properties repeatedly.
function AddCommonConfig(oProj, strProjectName,bAddUnicode,bForEmptyProject) in the sections for debug and/or release CLTool.DisableLanguageExtensions = true; // add to make the default NO MS extensions (but you probably don't want this for Boost code). LinkTool.LinkIncremental = linkIncrementalNo; // add CLTool.WarningLevel = WarningLevel_4; // change from 3 to 4 to making the default warning level 4
For GCC this means -Wall -pendantic
but you might consider adding specific warnings that are to be suppressed, for example:
-pedantic -Wall -Wno-long-long -Wno-unused-value
but this is a global setting, so you need to document that these warnings must be suppressed by users of this module. This may be acceptable if they are building a library of entirely Boost modules.
Using bjam add warnings=all to the invocation command line.
Putting options in jam files allows setting to be made for one or more specified compiler(s).
Some sample options in jamfile.v2 are:
project
: requirements
<toolset>gcc:<cxxflags>-Wno-missing-braces
<toolset>darwin:<cxxflags>-Wno-missing-braces
<toolset>acc:<cxxflags>+W2068,2461,2236,4070,4069 # Comments on warning message help readers who do not have ACC documentation to hand.
<toolset>intel:<cxxflags>-nologo
<toolset>msvc:<warnings>all # == /W4
-<toolset>msvc:<define>_DEBUG # Undefine DEBUG.
<toolset>msvc:<define>NDEBUG # Define NO debug, or release.
<toolset>msvc:<asynch-exceptions>on # Needed for Boost.Test
# <toolset>msvc:<cxxflags>/Za # Disable MS extensions, if required, but see above.
#-<toolset>msvc:<cxxflags>/Za # (Re-)Enable MS extensions if these are definitely required for specific module.
# The define of macros below prevent warnings about the checked versions of SCL and CRT libraries.
# Most Boost code does not need these versions (as they are markedly slower).
<toolset>msvc:<define>_SCL_SECURE_NO_WARNINGS
<toolset>msvc:<define>_SCL_SECURE_NO_DEPRECATE
<toolset>msvc:<define>_CRT_SECURE_NO_WARNINGS
<toolset>msvc:<define>_CRT_SECURE_NO_DEPRECATE
<toolset>msvc:<define>_CRT_NONSTDC_NO_DEPRECATE # Suppresses other warnings about using standard POSIX and C9X.
# Alternatively, you can just suppress the warnings (perhaps not the best way).
<toolset>msvc:<cxxflags>/wd4996 # 'putenv': The POSIX name for this item is deprecated.
<toolset>msvc:<cxxflags>/wd4512 # assignment operator could not be generated.
<toolset>msvc:<cxxflags>/wd4224 # nonstandard extension used : formal parameter 'arg' was previously defined as a type.
<toolset>msvc:<cxxflags>/wd4127 # expression is constant.
<toolset>msvc:<cxxflags>/wd4701 # unreachable code - needed for lexical cast - temporary for Boost 1.40 & earlier.
...
;
Defining warnings as errors
Using warning-as-errors will make it hard to miss or ignore warnings. Microsoft command line option /WX, makes all warnings errors, but this may be too drastic a step.
The following have been recommended by Pete Bartlett to make the MSVC and GCC compilers behave as similarly as possible:
/we4288 - For-loop scoping (this is the default)
/we4238 - don't take address of temporaries
/we4239 - don't bind temporaries to non-const references (Stephan's "Evil Extension")
/we4346 - require "typename" where the standard requires it.
and compile options:
/Zc:forScope - For loop scoping again (this is the default).
/DNOMINMAX - Don't define min/max macros (usually only applies if windows.h is involved). (Note that suitable bracketing, for example, (std::numeric_limits<result_type>::max)(), will avoid clashes with min/max macros, and is required to avoid being named'n'shamed by the Boost inspection program. So it may be better to check that clashes are correctly avoided by bracketing because others may use when min/max macros are defined rather than using this compiler option.)
gcc option -warning-as-errors gcc option -pedantic-errors
2 Consider each warning and
a Rewrite the code to avoid the warning, if possible. For example, adding a static_cast will indicate that any warning about loss of accuracy has been judged not possible or significant. Remove or comment out parameters to avoid warnings about unused parameters. Placing /* comment */ around an unused variable name, allows the name still to be useful documentation.
b Use the compiler specific mechanism to suppress the warning message, but try hard to ensure that this is as local to the package as possible so that users can still get warnings from *their code*.
For MSVC, this involves pushing to save the current warning state, disabling the warning, and later popping to restore (abbreviated as push'n'pop). See [@http://msdn.microsoft.com/en-us/library/2c8f766e%28v=VS.100%29.aspx warnings]
There is a limit to how many times (56) this can be used, so it is always much better to 'fix' than to suppress warnings.
"The compiler only supports up to 56 #pragma warning statements in a compiland"
This limit might be reached in practice with Boost code.
But it is now believed that this limit value is incorrect and that there is no practical limit, see post by Stephan T. Lavavej
On GCC there does not appear to be a practical limit, see post by Patrick Horgan.
#if defined(_MSC_VER) #pragma warning(push) // Save warning settings. #pragma warning(disable : 4996) // Disable deprecated localtime/gmtime warning. #endif ... #if defined(_MSC_VER) #pragma warning(pop) // Restore warnings to previous state. #endif
Adding some or all of the warning message as a comment is helpful to tell readers what warning is being ignored, for example:
# pragma warning(disable: 4510) // default constructor could not be generated
If the warning is only for a specific compiler version, use this approach:
#if BOOST_WORKAROUND(BOOST_MSVC, >= 1400) #pragma warning(push) #pragma warning(disable:4512) //assignment operator could not be generated #endif ... #if BOOST_WORKAROUND(BOOST_MSVC, >= 1400) #pragma warning(pop) #endif
c Repeat this process with other compilers and use their specific suppression methods.
d If a warning cannot be eliminated or suppressed, explain why in the code and the documentation. If appropriate, document in build files, as well. Consider indicating the highest warning level possible or compiler-specific settings that will provide a warning-free build.
Specific Warnings and Suggested Actions.
These are just few for starters, and need more, especially for gcc. Suggestions may be wrong!
The pragma or other code required to suppress warnings is in the right hand box, ready for copy and paste.
Microsoft
If you chose to suppress (rather than fix by recoding), localise the warnings as far as possible by using push'n'pop pragmas (see above).
| Warning | Warning Description | Suggestions | Suppression |
| C4100 | unreferenced formal parameter | Either surround the parameter with C comments, for example: int */ my_variable */)or just delete if the variable name is uninformative. If in other's module(s), or you are too busy/idle, at least suppress warning. In generic code you might not be able to comment the variable name as it might actually be used to call a static function. In this case simply referencing the variable (varname;) in the function body eliminates the warning. | # pragma warning(disable: 4100) 'name' : unreferenced formal parameter |
| C4127 | conditional expression is constant | Very common and many believe unhelpful, but a few find it informative, so do not suppress globally. Even while(true) can trigger this! Suppress. while(true) can be rewritten as for(;;) eliminating the warning. | # pragma warning(disable: 4127) conditional expression is constant. |
| C4146 | unary minus operator applied to unsigned type, result still unsigned | This indicates a real error. | Fix. |
| C4180 | qualifier applied to function type has no meaning; ignored | The meaningless qualifier can always be removed (or left as a comment if it informative) - but check that you didn't mean to put the const somewhere else. can always be suppressed. | # pragma warning(disable: 4180) qualifier applied to function type has no meaning; ignored |
| C4189 | local variable is initialized but not referenced | This probably indicates a redundant variable and assignment, so probably remove it. If you are sure it is required (or has negligible cost for some documentation benefit), suppress. | # pragma warning(disable: 4189) local variable is initialized but not referenced |
| C4224 | nonstandard extension used : formal parameter 'arg' was previously defined as a type. | This will bite users who try to compile with Microsoft extensions disabled. Wrong warning acknowledged by MS as a bug http://tinyurl.com/2blmq3l but won't be fixed. May be a major nuisance to change the names in the code but suppressing is fine. | # pragma warning(disable: 4224) formal parameter 'arg' was previously defined as a type. |
| C4244 | Conversion: possible loss of data. | Fix, for example changing type or using static_cast is best, suppress with much caution. | # pragma warning(disable:4244) Conversion: possible loss of data. |
| C4324 | structure was padded due to declspec(align()) | Suppress | #pragma warning(disable:4324) structure was padded due to declspec(align()) |
| C4503 | decorated name length exceeded | Suppress. (Note that \boost\config\compiler\visualc.hpp includes this global suppression: #pragma warning(disable:4503) | #pragma warning( disable : 4503 ) warning: decorated name length exceeded |
| C4506 | no definition for inline function | Provide a definition, or if you cannot/will not, suppress. | # pragma warning(disable: 4506) no definition for inline function |
| C4512 | assignment operator could not be generated | Suppress using push'n'pop for the module(s) causing the warning. Adding the declaration (not the definition) of the appropriate operator=() as a private member does the trick as well. | # pragma warning(disable: 4512) assignment operator could not be generated. |
| c4511 | copy constructor could not be generated. | Provide constructor (and assignment operator and destructor). Or suppress. | # pragma warning(disable: 4511) copy constructor could not be generated |
| C4510 | default constructor could not be generated. | If have reference or const members provide default constructor with initializer list. If intent is to make non-default-constructable, provide private declaration only. Suppress. | # pragma warning(disable: 4510) default constructor could not be generated |
| C4535 | calling _set_se_translator() requires /EHa | Common from Boost.Test. In jamfile, add to project : requirements | <toolset>msvc:<asynch-exceptions>on # calling _set_se_translator() requires /EHa |
| C4625 | copy constructor could not be generated because a base class copy constructor is inaccessible | Trying to derive from a non-copyable class? Bug? | Fix. |
| C4626 | assignmentconstructor could not be generated because a base class copy constructor is inaccessible | Trying to derive from a non-copyable class? Bug? | Fix. |
| C4671 | the copy constructor is inaccessible | Suppress? | #pragma warning(disable: 4671) the copy constructor is inaccessible |
| C4673 | A throw object cannot be handled in the catch block. | Fix ? | #pragma warning(disable: 4673) Thrown object cannot be handled in catch block. |
| C4701 | local variable may be used without having been initialized | Best is to recode to avoid the message, probably just initialising it. But if you are very sure the message is misleading, and cost of dummy initialisation too high, suppress. | # pragma warning(disable: 4701) local variable may be used without having been initialized |
| C4702 | unreachable code | Best delete or comment-out. Be very cautious about suppressing this, but use of macros may make this troublesome, so suppress with care, and always locally. | #pragma warning(disable: 4702) unreachable code |
| C4710 | 'function' : function not inlined | If variable is volatile, suppress. | #pragma warning(disable: 4510) function not inlined. |
| C4725 | inline assembly instruction that may not produce accurate results on some Pentium microprocessors. | Now obselete. Suppress. | #pragma warning(disable: 4510) inaccurate results on some Pentium microprocessors? |
| C4800 | int' : forcing value to bool 'true' or 'false' | Use a bool valued expression. Write out expressions, for example: "value >= 0" or "ptr != 0" (Boost prefers clarity to curtness). Take care if using templates that constants are of the right type, for example you may need "value == static_cast<T>(1)". Or use static_cast<bool>(expression). Or suppress. | # pragma warning(disable: 4800) int' : forcing value to bool 'true' or 'false' |
| C4996 | 'putenv': The POSIX name for this item is deprecated (but NOT by POSIX!). | Suppress. | # pragma warning(disable: 4996) 'putenv' was declared deprecated. |
| C4996 | ' this item is deprecated. | Many similar messages suggest using secure versions. Unless you strongly believe that the 'secure' versions are useful, suppress. WG14 Austin Group concerns may guide. See also _CRT_SECURE_NO_DEPRECATE and other defines above. | # pragma warning(disable: 4996) was declared deprecated. |
| C6385 | invalid data: accessing <buffer name>, the readable size is <size1> bytes, but <size2> bytes may be read. | Code analyser False warning C6385 when a function result is used as an array index. See https://connect.microsoft.com/VisualStudio/feedback/details/281033/ suggests this can be suppressed, unless a check on array bounds is wanted/necessary. |
Warnings for GCC
With older versions of GCC, it is more difficult to deal with warnings because there is no way to locally silence individual warnings. As of GCC version 4.2 they allowed suppression via pragma (actually you can choose whether a particular problem is a warning, error, or ignored). Initially they didn't allow you to save the current state of affairs, so after suppressing the warning, you wouldn't know whether the user had it on, off, or causing an error. You can imagine that this would be quite annoying for users who care about these things. Also, the pragmas had to be at file scope rather than inside your code. As of version 4.6 a pragma was added to push or to pop the state of diagnostics, and the pragmas now affect from the line they are specified in forward. It is considered important not to leave warnings switched off when meeting user code. This is an unresolved difficulty when using GCC versions prior to 4.6.
On the other hand, the number of unhelpful warnings seems fewer.
So more emphasis should be placed on fixing warnings, for example using static_cast, or providing missing items.
Suppressing Warnings
Supressing Warnings For A File By Making GCC See It As A System Header
For a particular file, you can turn off all warnings including most warnings generated by the expansion of macros specified in a file by putting the following in a file
#pragma GCC system_header File considered a system header.
Note that this works differently depending on the version of GCC prior to version 4.6 it needed to be put near the beginning of the file and before any code. All code in the file after the pragma is seen will be considered system code. Since 4.6, it can be specified anywhere in the file, and code that precedes the pragma in the file will be unaffected. The intent of declaring a file a system header, is for operating system specific code that can't be strictly conforming C or C++. This should not be seen as a handy way of turning off bothersome warnings. Many (most?) warnings point to real issues and should be dealt with appropriately.
You can also turn off warnings for all files in a directory, by putting the directory into the include search path with -i instead of -I
The -idirectoryName command line option adds its argument to the list of directories to search for headers, just like -I. Any headers found in that directory will be considered system headers. It also has the side effect of changing the inclusion order, in that all files included from directories specified with -i are included after files included from directories specified via -I. If the directory is specified with both -I and -i it is still only searched after normal includes as part of the system include directories. This may be appropriate if you have to deal with other's spotty code that generates a lot of warnings that you can't fix.
If you turn off warnings for files that are shared with your users, you need to be able to see the warnings yourself so that as new problems arise you will see them. You can turn on warnings back on for system headers with:
-Wsystem-headers
Print warning messages for constructs found in system header files that would normally not be seen. Warnings from system headers are normally suppressed, on the assumption that they usually do not indicate real problems and would only make the compiler output harder to read. Using this command line option tells GCC to emit warnings from system headers as if they occurred in user code. However, note that using -Wall in conjunction with this option will not warn about unknown pragmas in system headers—for that, -Wunknown-pragmas must also be used.
Turning off warnings locally
So. Suppose you are getting a warning and have checked the code and are sure that it's a spurious warning. There's nothing wrong. If the warning is controllable via a command line -W option, then you can (if you have GCC version 4.2.4 or newer) turn it off temporarily. First you need to find out what the option might be, then if it exists turn it off via a pragma. How you do this varies a bit with GCC version.
- -fdiagnostics-show-option
- In GCC, for versions 4.2.4 and higher, this option instructs the diagnostic machinery to add text to each diagnostic emitted, which indicates which command line option directly controls that diagnostic, when such an option is known to the diagnostic machinery.
- #pragma GCC diagnostic push
- Available since GCC version 4.6, this pragma lets you remember diagnostic options in place at a particular time. This pragma can occur on any line of a file.
- #pragma GCC diagnostic pop
- Available since GCC version 4.6, this pragma lets you restore diagnostic options that were remembered by a diagnostic push. This pragma can occur on any line of a file.
- #pragma GCC diagnostic [warning|error|ignored] OPTION
- From GCC version 4.2.4 and before GCC version 4.6 this could be specified at file scope outside of any functions, classes, unions, structs, or methods, to change the behavior when a particular class of error was seen. For GCC version 4.6 and later, it can be put in any line of a file, and affects from that position forward. For any supported version, it only works with warnings that have explicit -W arguments, use -fdiagnostic-show-option to find out which one to use. An example: #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
So starting from 4.2.4 but before 4.6, just put near the top of the file something like:
#pragma GCC diagnostic ignored "-Wdeprecated-declarations
For version 4.6 or later, you can insert this around the line that causes the spurious warning:
#pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
Next you would have your code that generates the spurious warning
#pragma GCC diagnostic pop
Turning on Warnings
-Wall
This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros. This also enables some language-specific warnings described in C++ Dialect Options and Objective-C and Objective-C++ Dialect Options. For specific information on any of these warnings please see http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
-Wall turns on the following warning flags:
-Waddress -Warray-bounds (only with -O2) -Wc++0x-compat -Wchar-subscripts -Wimplicit-int -Wimplicit-function-declaration -Wcomment -Wformat -Wmain (only for C/ObjC and unless -ffreestanding) -Wmissing-braces -Wnonnull -Wparentheses -Wpointer-sign -Wreorder -Wreturn-type -Wsequence-point -Wsign-compare (only in C++) -Wstrict-aliasing -Wstrict-overflow=1 -Wswitch -Wtrigraphs -Wuninitialized -Wunknown-pragmas -Wunused-function -Wunused-label -Wunused-value -Wunused-variable -Wvolatile-register-var
Note that some warning flags are not implied by -Wall. Some of them warn about constructions that users generally do not consider questionable, but which occasionally you might wish to check for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning. Some of them are enabled by -Wextra but many of them must be enabled individually.
-Wextra
This enables some extra warning flags that are not enabled by -Wall. (This option used to be called -W. The older name is still supported, but the newer name is more descriptive.)
-Wclobbered -Wempty-body -Wignored-qualifiers -Wmissing-field-initializers -Wmissing-parameter-type (C only) -Wold-style-declaration (C only) -Woverride-init -Wsign-compare -Wtype-limits -Wuninitialized -Wunused-parameter (only with -Wunused or -Wall)
The option -Wextra also prints warning messages for the following cases:
- A pointer is compared against integer zero with
<',<=',>', or>='. - (C++ only) An enumerator and a non-enumerator both appear in a conditional expression.
- (C++ only) Ambiguous virtual bases.
- (C++ only) Subscripting an array which has been declared `register'.
- (C++ only) Taking the address of a variable which has been declared `register'.
- (C++ only) A base class is not initialized in a derived class' copy constructor.
More information needed here!
Specific Warnings and Suggested Actions
comparison between signed and unsigned integer expressions
-Wsign-compare - enable the warning (also turned on by -Wextra)
-Wno-sign-compare - disable the warning
Almost always points to a real issue. The ranges of these are obviously different, for example signed char -128 - 127 and unsigned char 0 - 255 for
range bit pattern signed char -128 to 127 01111111 to 10000000 unsigned char 0 to 255 00000000 to 11111111
That means: signed char unsigned char 0 to 127 + + 128 to 255 \- /+
In the range from 128 to 255 a comparison from one to the other makes no sense. They can have the same bit pattern, yet test as not equal. This is the source of many subtle and hard to find bugs.
The same problem can occur with all of the integral types. For example with 16-bit short int unsigned ranges from -32768 to 32767, and the signed short ranges from 0 to 65535.
To fix, if you are sure that all the values for both things being compared fall into the overlap where their values are the same, you can static_cast one type to the other, if you must, but if you can change one of the types it's a better solution. If you are sure that you can fit all values into the compared range, i.e. positive numbers from 0 to (1<<(sizeof(IntegralType)*8-1))-1, it would make more sense to declare the signed one as an unsigned equivalent, (perhaps size_t). In general, if you don't intend for a variable to ever have negative values, take advantage of the diagnostic capabilities of the compiler and declare it as an unsigned type, often size_t. After you've done this, if you see the warning again for one of these same variables, it is warning you of this same danger again.
This often shows up with loop counters. We all learned to use int, but if it's truly counting only positive numbers, size_t is better.
missing braces around initializer for ‘main()::X
-Wmissing-braces - enable the warning (also turned on by -Wall)
-Wno-missing-braces - disable the warning
This warning is trying to let you know that what you think you're initializing may not actually be what you're initializing.
struct X { int i; int j;};
struct Y { struct X x; int j; };
Y y={1,2};
return 0;
The above example initializes both the elements of X in Y, but doesn't initialize j. Change to:
Y y={{1},2};
to initialize half of X and all of Y, or better something like:
Y y={{1,2},3};
The same kind of problem can come up with:
int a[2][2]={ 0, 1, 2 };
versus:
int a[2][2]={ {0,1},2};orint a[2][2]={ 0, {1,2}};
deprecated conversion from string constant to ‘char*’
-Wwrite-strings - enable this warning (disabled by default for C and enabled by default for C++) -Wno-write-strings - disable this warning
For C will warn about trying to modify string constants, but only if defined const. For C++ often symptomatic of a real bug since string literals are not writeable in C++.
This one shows up when you have a string literal, like "Hello world!" which is arguably const data, and you assign it no a non-const char* either directly or via passing as an argument to a functions which expects a non-const char *. both:
char* cp="Hello world!";and
void foo(char *cp); foo("Hello world")will get this warning because you're using a string literal where a char* is expected. If you say, so what? See if you can predict what will print in the example below.
#include <iostream>
void
foo(char *cp)
{
cp[0]='W';
}
int main()
{
char *str="Hello, world";
foo(str);
std::cout << str << std::endl;
}
If you said that Wello, world will print, think again. Your most likely output is something like:
Segmentation fault (core dumped)
A string literal is put into a section that is read only and trying to write to it makes things blow up!
The right fix is to make anything that a string literal can be assigned to a const char*. Unfortunately, sometimes you can't fix the problem at the source, because it's someone else's code, and you can't change the declaration. For example, if you had this function:
int PyArg_ParseTupleAndKeywords(PyObject *arg, PyObject *kwdict,
char *format, char **kwlist, ...);
and you had a keyword list to pass it that looked like this:
static char *kwlist[] = {"fget", "fset", "fdel", "doc", 0};
if (!PyArg_ParseTupleAndKeywords(args, kwds, "|OOOO:property",
kwlist, &get, &set, &del, &doc))
you would get the warning on the kwlist assignment, because you're assigning a const char * to char *, but when you correctly change it to:
static const char *kwlist[] = {"fget", "fset", "fdel", "doc", 0};
to get rid of the waring you'll get a warning on the call to PyArg_ParseTupleAndKeywords:
error: invalid conversion from ‘const char’ to ‘char’
because the library function was declared as taking a char for the fourth argument. Your only recourse is to cast away the constness with a const_cast:
if (!PyArg_ParseTupleAndKeywords(args, kwds, "|OOOO:property",
const_cast<char **>(kwlist), &get, &set, &del, &doc))
Annoying, yet more correct than before.
dereferencing type-punned pointer will break strict-aliasing rules
this warning is only active when strict-aliasing optimization is active
-Wstrict-aliasing - equivalent to -Wstring-aliasing=3 (included in -Wall)
-Wstrict-aliasing=N where N is in {1,2,3} - Higher N implies less false positives, at the expense of more work. Currently there are 3 levels.
Level 1: Most agressive, quick, very few false negatives, but many false positives. Might use if higher levels don't warn, but turning on -fstrict-aliasing breaks the code. Warns about pointer conversions even if pointer not dereferenced.
Level 2: Agressive, quick, not too precise. Less false positives than Level 1, but more false negatives. Only warns if pointer is dereferenced.
Level 3: Very few false positives and very few false negatives--the default.
-fstrict-aliasing - also turned on by -O2, -O3 and -Os. Tells the compiler that it's ok to do a certain class of optimization based on the type of expressions. In particular you're promising by using this flag that an object of one type won't reside at the same address as an object of an incompatible type. -fno-strict-aliasing - turns off this optimization. If this changes the behavior of your code, you have a problem in your code.
This is trying to let you know that you are asking the compiler to do undefined behavior and it may not do what you think it will do. As the optimization level increases, the liklihood that you won't like what it does will increase. I show a simple example later that surprisingly generates the wrong result when optimization at any level is turned on. Ignore this warning at your own peril. You are unlikely to care for the undefined behavior that results.
From the C++ Standard, section 3.10 Lvalues and rvalues 15 If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined — the dynamic type of the object, — a cv-qualified version of the dynamic type of the object, — a type similar (as defined in 4.4) to the dynamic type of the object, — a type that is the signed or unsigned type corresponding to the dynamic type of the object, — a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object, — an aggregate or union type that includes one of the aforementioned types among its member (including, recursively, a member of a subaggregate or contained union), — a type that is a (possibly cv-qualified) base class type of the dynamic type of the object, — a char or unsigned char type.
The following program generates 6 warnings about breaking strict-aliasing rules, and many would dismiss them. The correct output of the program is:
00000020 00200000
but when optimization is turned on it's:
00000020 00000020
THAT's what the warning is trying to tell you, that the optimizer is going to do things that you don't like. In this case seeing that acopy is set to a and never touched again, strict aliasing lets it optimize by just returning the original value of a at the end.
uint32_t
swaphalves(uint32_t a)
{
uint32_t acopy=a;
uint16_t *ptr=(uint16_t*)&acopy;// can't use static_cast<>, not legal.
// you should be warned by that.
uint16_t tmp=ptr[0];
ptr[0]=ptr[1];
ptr[1]=tmp;
return acopy;
}
int main()
{
uint32_t a;
a=32;
cout << hex << setfill('0') << setw(8) << a << endl;
a=swaphalves(a);
cout << setw(8) << a << endl;
}
Here's the (annotated) x86 assembler generated by gcc 4.4.1 for swaphalves, let's see what went wrong:
_Z10swaphalvesj:
pushl %ebp
movl %esp, %ebp
subl $16, %esp
movl 8(%ebp), %eax # get a in %eax
movl %eax, -8(%ebp) # and store in in acopy
leal -8(%ebp), %eax # now get eax pointing at acopy (ptr=&acopy)
movl %eax, -12(%ebp) # save that ptr at -12(%ebp)
movl -12(%ebp), %eax # get the ptr back in %eax
movzwl (%eax), %eax # get 16 bits from ptr[0] in eax
movw %ax, -2(%ebp) # store the 16 bits into tmp
movl -12(%ebp), %eax # get the ptr back in eax
addl $2, %eax # bump up by two to get to ptr[1]
movzwl (%eax), %edx # get that 16 bits into %edx
movl -12(%ebp), %eax # get ptr into eax
movw %dx, (%eax) # store the 16 bits into ptr[1]
movl -12(%ebp), %eax # get the ptr again
leal 2(%eax), %edx # get the address of ptr[1] into edx
movzwl -2(%ebp), %eax # get tmp into eax
movw %ax, (%edx) # store into ptr[1]
movl -8(%ebp), %eax # forget all that, return original a.
leave
ret
Scary, isn't it? Of course you could use -fno-strict-aliasing to get the right output, but the generated code won't be as good. A better way to accomplish the same thing without the warning's or the incorrect output is to define swaphalves like this:
uint32_t
swaphalves(uint32_t a)
{
union swapem{
uint32_t a;
uint16_t b[2];
};
swapem s={a};
uint16_t tmp;
tmp=s.b[0];
s.b[0]=s.b[1];
s.b[1]=tmp;
return s.a;
}
The C++ compiler knows that members of a union alias, and this helps the compiler generate MUCH better code:
_Z10swaphalvesj:
pushl %ebp # save the original value of ebp
movl %esp, %ebp # point ebp at the stack frame
movl 8(%ebp), %eax # get a in eax
popl %ebp # get the original ebp value back
roll $16, %eax # swap the two halves of a and return it
ret
| ? | class does not have a virtual destructor | Suppress or provide a virtual destructor. | ?? |
Intel
Information needed here.
Darwin /MacOS
Information needed here.
ACC
Information needed here.
Borland
Information needed here.
Sun
some Sun workarounds to some Sun compiler errors/warnings.
