How to Disable Specific Warning When -Wall Is Enabled

how to disable specific warning when -Wall is enabled

This way

How can I disable -Wc++0x-compat when using -Wall?

-Wno-c++0x-compat​​​​​​​​​​​​​​​​​​​

How to disable a warning which gets re-enabled in third-party code?

From experience with very similar issues (but with the in-built Windows 'system' headers, rather than 3rd-party stuff), I have reluctantly accepted the fact that the #pragma warning (push|pop) system doesn't really work! This seems especially true when the "Enable all warnings" (/Wall) option is set, as the #pragma warning(pop) doesn't understand what 'level number' to restore.

The only workable technique I have (so far) come up with is to explicitly disable the relevant warnings before inclusion of the '3rd-Party' headers, then (again, explicitly) reset them afterwards. Here is a short extract from the "global" header (the one I use to generate the pre-compiled header) I use for building my projects:

// Turn off warnings generated by the "standard" and "MFC" header files.  *** Note: using "#pragma(push, 2) ...
// #pragma(pop)" to embrace these header files doesn't work! *** [For some reason (possibly something weird in
// one of the headers), warnings such as 'unused parameters' and 'signed/unsigned' are not re-enabled.] ...
#pragma warning(disable:4091) // 'typedef' ignored on left of tagGPFIDL.
#pragma warning(disable:4191) // unsafe conversion to AFX_PMSG(W) (MMAP)
#pragma warning(disable:4239) // Non-standard: conv. <class> to &<class>
#pragma warning(disable:4251) // class 'XXX' needs to have dll-interface
#pragma warning(disable:4263) // member function does not override . ...
//... and around 30 or so other, similar lines.

#include <afxwin.h> // Minimal set of afx... (MFC) headers for the things we want to do ... (?)
#include <afxwinappex.h> // Required for the base application class: MFC's CWinAppEx
#include <afxmdiframewndex.h> // Base frame windows "CMDIFrameWndEx" and "CMDIChildWndEx"
#include <mmsystem.h> // Mulitmedia APIs: allows playing of sounds in various alert message boxes
#include <MsiQuery.h> // Required for DLL interface to the MSI installer (itself #includes msi.h)
//... and all other warning-prone headers ...

#pragma warning(default:4091) // 'typedef' ignored on left of tagGPFIDL.
#pragma warning(default:4191) // unsafe conversion to AFX_PMSG(W) (MMAP)
#pragma warning(default:4239) // Non-standard: conv. <class> to &<class>
#pragma warning(default:4251) // class 'XXX' needs to have dll-interface
#pragma warning(default:4263) // member function does not override . ...
//... and all the others corresponding to those that were disabled

Note that, by using the #pragma warning(default:nnnn) (rather than #pragma warning(enable:nnnn)) you are resetting the warning to the project's setting, rather than blindly enabling it.

I understand that this is rather clumsy - and, almost certainly, not what you are looking or - but it does work. Also, once you have established the basic list of warnings, it's a relatively low-maintenance solution.

PS: As far as I am aware, there is no option available to the MSVC pre-processor to either detect or change the /WX (treat warnings as errors) compiler option, although you can set this for any specific warning, with #pragma warning(error:nnnn), and 'unset' it using default.


EDIT: Another possible way of disabling the following:

warning C4505: 'bar': unreferenced local function has been removed

is to actually reference the 'offending' function. But I'm not here being sarcastic - you can include a dummy static inline function that references bar (in your header) and that will silence the warning (it isn't given for functions defined as static inline). So, assuming the function bar is defined (in the 3rd-party header) like this:

static int bar(int b)
{
return b * b;
}

but bar is never referenced in (some of) your build units, then adding this line to your 'global' header (after the inclusion of the 3rd-party header) will kill the warning (for MSVC, but not for clang-cl):

static inline int foo(int a) { return bar(a); }

Of course, if there are many such warnings, this method could become a bit cumbersome; but again, once you have the code written, it's low-maintenance.

How can I disable a C/C++ `-Werror` build error in Bazel? (AKA: how to turn OFF specific warnings already turned on by `-Wall -Werror`)

The answer is to use the -Wno-error=<name> build flag, as described by gcc here (note that clang's options are modeled after gcc):

-Werror=

Make the specified warning into an error. The specifier for a warning is appended; for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings; for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect.

The warning message for each controllable warning includes the option that controls the warning. That option can then be used with -Werror= and -Wno-error= as described above.

Source: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html (emphasis added).

So, for this case, add the build option -Wno-error=undefined-reinterpret-cast to turn OFF the -Werror=undefined-reinterpret-cast flag.

In Bazel, you can pass C/C++ build options with the --copt="<flag>" option (see here) (see also the --per_file_copt option (see here and here)), making the final command look like this for this case:

time bazel build --copt="-Wno-error=undefined-reinterpret-cast" //my/src/...

This works! The Bazel build now runs to completion, showing these problems only as warnings again (notice -Werror is missing from the warning statement now):

...has undefined behavior [-Wundefined-reinterpret-cast]

Note that if you need to pass multiple build flags in at once, use multiple calls to --copt=. Ex:

time bazel build --copt="-Wno-error=undefined-reinterpret-cast" \
--copt="-Wno-error=switch" --copt="-ggdb" --copt="-O0" //my/src/...

Note: don't ever do this on production code for potentially-serious warnings like this (ex: undefined behavior). For more benign warnings, this is the right technique if you really need to disable one. For undefined behavior, this should just be for learning. See my comment below this answer.

More reading:

  1. I've documented a lot of the above information, and more, in my eRCaGuy_hello_world repo under the section titled "Additional C and C++ build notes (ex: w/gcc or clang compilers)", here. Read there to learn more.
  2. [I STILL NEED TO TRY AND TEST THIS OUT] https://nelkinda.com/blog/suppress-warnings-in-gcc-and-clang/ - see esp. Section "3.3 Suppressing Warnings by Controlling the Diagnostic Stack". Learn to enable/disable GCC and Clang compiler warnings and options just for certain files or sections of code. Consider putting the necessary #pragma statements above and below header file #include statements to affect just those files.

Automatically know if a GCC/Clang warning comes from Wall or Wextra?

There's no specific command to get a direct answer to the question "which warning group does a given warning come from?", but it's possible to infer this information automatically by querying the compiler which warnings are enabled and checking if the warning we are interested in is part of the list of enabled warnings.

This is done as follows:

  • GCC: gcc -Q -Wall --help=warnings | grep enabled | grep unused-parameter (credits to @dratenik).
  • Clang: this functionality is not baked into the compiler, unlike GCC, so we need to use the diagtool tool: diagtool show-enabled -Wall foo.cpp | grep unused-parameter.

Bonus:
Unrelated to the original question but related to the original use case: to be sure that all of Wall and Wextra are enabled, regardless of which warnings are disabled, the solution (only works for Clang) is to put Wall Wextra at the very end:

clang -Wno-unused-parameter -Wall -Wextra

In this case, if we accidentally disable the unused-parameter warning, Wall will be applied after, re-enabling the warning.

Selectively remove a warning message using GCC

If you need that code to work portable then you should cast the argument to unsigned int, as the int type may have a different size than Int32 on some platforms.

To answer your question about disabling specific warnings in GCC, you can enable specific warnings in GCC with -Wxxxx and disable them with -Wno-xxxx.

From the GCC Warning Options:

You can request many specific warnings with options beginning -W, for example -Wimplicit to request warnings on implicit declarations. Each of these specific warning options also has a negative form beginning -Wno- to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default.

For your case the warning in question is -Wformat

-Wformat

Check calls to printf and scanf, etc., to make sure that the arguments supplied have types appropriate to the format string specified, and that the conversions specified in the format string make sense. This includes standard functions, and others specified by format attributes (see Function Attributes), in the printf, scanf, strftime and strfmon (an X/Open extension, not in the C standard) families (or other target-specific families). Which functions are checked without format attributes having been specified depends on the standard version selected, and such checks of functions without the attribute specified are disabled by -ffreestanding or -fno-builtin.

The formats are checked against the format features supported by GNU libc version 2.2. These include all ISO C90 and C99 features, as well as features from the Single Unix Specification and some BSD and GNU extensions. Other library implementations may not support all these features; GCC does not support warning about features that go beyond a particular library's limitations. However, if -pedantic is used with -Wformat, warnings will be given about format features not in the selected standard version (but not for strfmon formats, since those are not in any version of the C standard). See Options Controlling C Dialect.

How to suppress warnings from internal Visual Studio files

Maybe this will do the trick:

// you can replace 3 with even lower warning level if needed 
#pragma warning(push, 3)

#include <Windows.h>
#include <crtdbg.h>
#include "math.h"
//include all the headers who's warnings you do not want to see here

#pragma warning(pop)

If you plan to port your code to a non MS environment then you may wish to wrap all used external headers in a specific header so that it can be changed when porting.



Related Topics



Leave a reply



Submit