91

I wold like to disable particular warnings for all files that are included, directly or indirectly, by particular include files. For example, I want to disable the warning "you are assigning a string literal to a char*", for all files or files included by files included by a #include <bar/*> (the star in my case means "anything may be here").

The reason is, some of the people I have to program with just can't use "const", so in the end I get lots of warnings about that particular string literal abuse. I would like to ignore those thousands of warnings coming from their code, so I can concentrate on the mistakes in my own code and fix them.

I use Intel C++ and GCC. Some of my buddies use clang, so I would be glad to hear solutions for that too.

Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • 2
    http://stackoverflow.com/questions/1079997/disable-specific-warnings-in-gcc and http://stackoverflow.com/questions/965093/selectively-disable-gcc-warnings-for-only-part-of-a-translation-unit and quite a few more. –  Jun 12 '11 at 12:10
  • Am I getting this right - if a file in question is included by ``, the warnings should be suppressed, and with `` not? – Xeo Jun 12 '11 at 12:11
  • @Neil thanks for the related links. Just to make it clear for others that may have some unwanted associations: The above two links are not dupe links! – Johannes Schaub - litb Jun 12 '11 at 12:13
  • @Xeo not that in particular. I can live with all warnings being disabled for that file. It doesn't have to have a specific include pattern. I suspect the way I formulated my question is a little unfortunate. – Johannes Schaub - litb Jun 12 '11 at 12:15
  • What compiler are you using? (Methods of suppressing warnings often differ by compiler.) – Ben Hocking Jun 12 '11 at 13:00
  • @Ben: Always been at the bottom of the question: "I use Intel C++ and GCC.". – Xeo Jun 12 '11 at 13:04
  • Just teach them to write `const`-correct code. – sbi Jun 12 '11 at 18:59
  • @sbi, that's a good idea. but it won't help with the already existing code. – Johannes Schaub - litb May 02 '15 at 08:59
  • @Johannes: Did you just reply to my comment four years belated?? :-o Anyway, always fix `const`-incorrect code. It's worth it. – sbi May 04 '15 at 11:05
  • Its been a while, you should really mark one of these answers correct ... – Fantastic Mr Fox Aug 04 '16 at 00:04
  • @ben none of them answer the question satisfactionally, I am afraid – Johannes Schaub - litb Aug 04 '16 at 06:09
  • Does this answer your question? [How to suppress GCC warnings from library headers?](https://stackoverflow.com/questions/1867065/how-to-suppress-gcc-warnings-from-library-headers) – ggorlen Feb 05 '20 at 20:13

5 Answers5

74

When using GCC you can use the -isystem flag instead of the -I flag to disable warnings from that location.

So if you’re currently using

gcc -Iparent/path/of/bar …

use

gcc -isystem parent/path/of/bar …

instead. Unfortunately, this isn’t a particularly fine-grained control. I’m not aware of a more targeted mechanism.

Konrad Rudolph
  • 530,221
  • 131
  • 937
  • 1,214
  • 4
    in clang there is --system-header-prefix= option, see http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-in-system-headers – dev_null Jul 14 '14 at 16:21
67

A better GCC solution: use #pragma.

#pragma GCC diagnostic push 
#pragma GCC diagnostic ignored "-W<evil-option>"
#include <evil_file>
#pragma GCC diagnostic pop

for example:

#pragma GCC diagnostic push 
#pragma GCC diagnostic ignored "-Wunused-local-typedefs"
#include <QtXmlPatterns>
#pragma GCC diagnostic pop
Brad
  • 3,190
  • 1
  • 22
  • 36
  • This is not what I want. I seek for a way to disable warnings for all files that start with "Qt" (to keep at your example. Not only for a single named file. We already use diagnostic push/pop, but unfortunately this cannot do a wildcard match on filenames as far as we've seen. – Johannes Schaub - litb May 02 '15 at 08:58
  • Sorry, I misunderstood. AFAIK, you only have two choices: create a header file that includes all the headers in question, wrapped in #pragma diagnostic and include it first (and count on multi-inclusion guards to process the files only once). Or, treat the headers as system headers with -isystem. I don't think there is a way to define custom diagnostic rules based on include path (beyond the behavior of isystem.) I've always used the "create an "include_all_bar.h" file" approach to this problem. – Brad May 04 '15 at 18:43
  • 15
    Have to say that while this answer isn't top-voted, I do think it is very useful. Although it doesn't quite meet the original question (all libraries in a path/prefix), it does provide a way to selectively exclude some warnings for a given set of headers. – benschumacher Oct 10 '18 at 16:13
40

When I use g++ and I have third party headers that generate tons of warnings with my usual defaults of -Wall -Wextra & co. I tend to group them in separate includes, specifying the system_header #pragma.

[...] GCC gives code found in system headers special treatment. All warnings, other than those generated by #warning (see Diagnostics), are suppressed while GCC is processing a system header. Macros defined in a system header are immune to a few warnings wherever they are expanded. This immunity is granted on an ad-hoc basis, when we find that a warning generates lots of false positives because of code in macros defined in system headers.

[...]

There is also a directive, #pragma GCC system_header, which tells GCC to consider the rest of the current include file a system header, no matter where it was found. Code that comes before the #pragma in the file will not be affected. #pragma GCC system_header has no effect in the primary source file.

I prefer this solution to the -isystem one because it's more fine-grained and I can put it directly in the sources, without messing too much with command line arguments and include directories.

Example with the hideous root library:

#ifndef ROOTHEADERS_HPP_INCLUDED
#define ROOTHEADERS_HPP_INCLUDED
#ifdef __GNUC__
// Avoid tons of warnings with root code
#pragma GCC system_header
#endif
#include "TH1F.h"
#include "TApplication.h"
#include "TGraph.h"
#include "TGraph2D.h"
#include "TCanvas.h"
#endif
Community
  • 1
  • 1
Matteo Italia
  • 123,740
  • 17
  • 206
  • 299
  • 2
    Ooh, very good. +1 … unfortunately, such files tend to come *before* other include files and applying the pragma seems to affect the rest of the file, i.e. *all* following includes. – Konrad Rudolph Jun 12 '11 at 12:41
  • @Konrad Rudolph: You sure about that? isn't it only for one include and its sub-includes? – Amir Zadeh Jun 12 '11 at 12:52
  • 2
    @Green Yes, that’s what I meant. Still, this requires me to either put all questionable includes at the end of the include list (and as I’ve said that’s often not desirable or even possible) *or* put all questionable includes into a separate header, which you then include. This is also not a perfect option in a large collaborative project. – Konrad Rudolph Jun 12 '11 at 13:33
  • 2
    @Konrad: the second solution is the one I adopted. – Matteo Italia Jun 12 '11 at 14:03
2

Copying my answer from a duplicate thread.

You could use suppression pragmas.

This is supported for GCC and VC++ compilers, and it looks like this:

#pragma warning(push)
#pragma warning(disable : 4244)
#pragma warning(disable : 4127)
#pragma warning(disable : 4512)
#include <boost/python.hpp>
#pragma warning(pop)

Here are the detailed specs:

Daniel Trugman
  • 8,186
  • 20
  • 41
0

I guess the simplest solution would be write a simple script that will call the compiler, compile, and strip the undesired output, based on the filename and warning type. You can use different scripts for each compiler.

Just update your makefile to use this script instead of calling the compiler directly.

Gilad Naor
  • 20,752
  • 14
  • 46
  • 53