Re: [lmi] [lmi-commits] master 1372a42 6/7: Use '-isystem' to suppress warnings in third-party headers

[Vadim Zeitlin]

On Mon, 8 Jun 2020 16:13:15 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 2020-06-08 11:51, Vadim Zeitlin wrote:
GC> > On Sun,  7 Jun 2020 18:03:29 -0400 (EDT) Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> [...]
GC> > GC> commit 1372a42340285f6f3604db30a371142b54261991
GC> [...]
GC> > GC>     Use '-isystem' to suppress warnings in third-party headers
GC> > 
GC> >  Funnily enough, a commit[1] with the message
GC> > 
GC> >   Replace `-isystem` compile flag with `-I`
GC> > 
GC> >   Using `-isystem` flag causes compilation errors with GCC10.
GC> >   Replace it with `-I` flag.
GC> > 
GC> > was merged into another project I follow/participate in just yesterday. 
And
GC> > the discussion of this commit links to gcc bug[2] where one of gcc
GC> > maintainers wrote
GC> > 
GC> >> you shouldn't use -isystem unless you really need to change the search
GC> >> order for system directories!
GC> > 
GC> > and recommended using GCC diagnostic pragmas for disabling the warnings
GC> > instead.
GC> 
GC> Fascinating. The documentation says something different:

 Yes, and I was surprised to read this because I always thought of -isystem
as a handy way to suppress warnings too (although I also used it when
cross-compiling, i.e. when you really need to change the search order).

GC> > GC>     Some third-party headers elicit warnings, which '-Werror' turns 
into
GC> > GC>     errors. There are several ways to avoid that:
GC> > GC>     
GC> > GC>     (1) Use pragmata to suppress the warnings before including such 
headers,
GC> > GC>        and "pop" their suppression right after including them. That 
doesn't
GC> > GC>        suppress warnings stemming from macros in those headers. In 
theory,
GC> > GC>        each such macro expansion could be surrounded by pragmata, but 
that's
GC> > GC>        tedious and ugly.
GC> > 
GC> >  I haven't tried it, but what about defining our own macros using pragmas
GC> > around the original macro invocation, shouldn't this work?
GC> 
GC> IOW, instead of
GC> 
GC>   #if defined __GNUC__
GC>   #   pragma GCC diagnostic push
GC>   #   pragma GCC diagnostic ignored "-Wcast-function-type"
GC>   #endif // defined __GNUC__
GC>   some_actual_code;
GC>   #if defined __GNUC__
GC>   #   pragma GCC diagnostic pop
GC>   #endif // defined __GNUC__
GC> 
GC> we could perhaps write
GC> 
GC>   WARNING_PUSH(list,of,warnings)
GC>   some_actual_code;
GC>   WARNING_POP
GC> 
GC> Is that what you have in mind?

 No, this was in reply to the "That doesn't suppress warnings stemming from
macros in those headers." part of your comment above and the idea was that
if some MACRO from a 3rd party header resulted in a warning, we could do

        #define LMI_MACRO(args) \
                _Pragma("GCC diagnostic push") \
                _Pragma("GCC diagnostic ignored \"-Wwhatever\"") \
                MACRO(args) \
                _Pragma("GCC diagnostic pop")

and use LMI_MACRO() in the code instead.

 Now that I think about it, I realize that we actually should do this
inside wxWidgets EVT_XXX macros themselves. Are there any other macros that
are problematic from this point of view?

GC>   https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
GC> | There is also a directive, #pragma GCC system_header, which tells GCC
GC> | to consider the rest of the current include file a system header, no
GC> | matter where it was found. Code that comes before the ‘#pragma’ in
GC> | the file is not affected. #pragma GCC system_header has no effect in
GC> | the primary source file.
GC> 
GC> That pragma could be added (before the first line of code) to every
GC> third-party header file, by such means as:
GC>  - convincing upstream maintainers to add it; or
GC>  - forcibly inserting it, e.g. with 'sed'.

 There is an additional problem with this approach, which also affects
"-isystem" one: I can imagine cases when a warning in a 3rd party header
would be _desirable_, i.e. when it would be given because the API is used
incorrectly.

GC> Anyway, my plan is to continue pursuing the '-isystem' method, and
GC> then go back later and consider whether there's a better way.

 I think using pragmas is a better way if we can solve the problem with the
macros as proposed above.

 Regards,
VZ

pgpw__VeEBHX3.pgp
Description: PGP signature