public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Sergey Bugaev <bugaevc@gmail.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH v2 2/3] cdefs.h: Define __glibc_warn_system_headers_{begin, end}
Date: Mon, 29 May 2023 11:50:58 -0300	[thread overview]
Message-ID: <1e0168d1-6175-aec2-bf35-f23aaf14e216@linaro.org> (raw)
In-Reply-To: <20230528172013.73111-3-bugaevc@gmail.com>



On 28/05/23 14:20, Sergey Bugaev via Libc-alpha wrote:
> By default, GCC supresses warnings inside "system headers". Moreover, it
> also supresses warnings resulting from expansion of macros defined in
> system headers, even in the expansion itself happens in user code. This
> may be desirable most of the time because the user cannot do anything
> about the mistakes of the system headers, but sometimes causing a
> warning is an intentional effect that a macro has, in which case this
> GCC feature gets in a way.
> 
> GCC allows turning off the warning suspension feature by passing
> -Wsystem-headers; however, that turns it off globally. But by using
> "#pragma GCC diagnostic" it can be made to only apply to the relevant
> macro definition, in which case GCC only does not supress warnings
> resulting from expansion of that one macro.
> 
> To that end, introduce __glibc_warn_system_headers_begin and
> __glibc_warn_system_headers_end macros that can be used to surround a
> macro definition and ensure that warnings inside the macro are not
> supressed:
> 
>     __glibc_warn_system_headers_begin
>     #define foo(x) bar_warn (x)
>     __glibc_warn_system_headers_end
> 
> This will be used in a following patch which turns fcntl and fcntl64
> into macros that cause warnings on argument type mismatch.
> 
> Note that "#pragma GCC diagnostic warning" normally overrides any
> diagnostic options specified on the command line, and so can even
> downgrade severity of a diagnostic from an error to a warning (if, for
> instance, -Werror is in effect). But this is not a concern here, since
> the actual warning that gets emitted is not "-Wsystem-headers", but some
> other specific warning; "-Wsystem-headers" is only used to disable its
> supression. So passing -Werror still causes the specific warning to be
> treated as an error, and to fail the compilation.
> 
> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
> ---
> 
> I'm not very sure about the prereq check. I stole it from the
> __glibc_macro_warning above (which also uses _Pragma), and according to
> the online docs GCC 4 has already supported -Wsystem-headers.

I think it should be OK to limit to GCC 4.8 and clang 3.5 (both support
-Wsystem-headers).

The patch look good to me, thanks.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

> 
>  misc/sys/cdefs.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h
> index 393d9091..d832d5c3 100644
> --- a/misc/sys/cdefs.h
> +++ b/misc/sys/cdefs.h
> @@ -649,6 +649,21 @@ _Static_assert (0, "IEEE 128-bits long double requires redirection on this platf
>  # define __glibc_macro_warning(msg)
>  #endif
>  
> +/* __glibc_warn_system_headers_begin starts a block of code where warnings
> +   produced by expanding macros defined in system headers will *not* be
> +   supressed.  __glibc_warn_system_headers_end ends such a block.  */
> +#if __GNUC_PREREQ (4,8) || __glibc_clang_prereq (3,5)
> +# define __glibc_warn_system_headers1(message) _Pragma (#message)
> +# define __glibc_warn_system_headers_begin \
> +  __glibc_warn_system_headers1 (GCC diagnostic push) \
> +  __glibc_warn_system_headers1 (GCC diagnostic warning "-Wsystem-headers")
> +# define __glibc_warn_system_headers_end \
> +  __glibc_warn_system_headers1 (GCC diagnostic pop)
> +#else
> +# define __glibc_warn_system_headers_begin
> +# define __glibc_warn_system_headers_end
> +#endif
> +
>  /* Generic selection (ISO C11) is a C-only feature, available in GCC
>     since version 4.9.  Previous versions do not provide generic
>     selection, even though they might set __STDC_VERSION__ to 201112L,

  reply	other threads:[~2023-05-29 14:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-28 17:20 [PATCH v2 0/3] fcntl fortification Sergey Bugaev
2023-05-28 17:20 ` [PATCH v2 1/3] support: Add support_fcntl_support_ofd_locks () Sergey Bugaev
2023-05-29 13:18   ` Adhemerval Zanella Netto
2023-05-28 17:20 ` [PATCH v2 2/3] cdefs.h: Define __glibc_warn_system_headers_{begin,end} Sergey Bugaev
2023-05-29 14:50   ` Adhemerval Zanella Netto [this message]
2023-05-28 17:20 ` [PATCH v2 3/3] io: Add FORTIFY_SOURCE check for fcntl arguments Sergey Bugaev
2023-05-29 16:54   ` Adhemerval Zanella Netto
2023-05-29 17:31     ` Sergey Bugaev
2023-05-29 18:09       ` Adhemerval Zanella Netto
2023-05-29 19:57         ` Sergey Bugaev
2023-05-29 20:14           ` Adhemerval Zanella Netto
2023-05-29 20:49             ` Sergey Bugaev
2023-05-29 21:09               ` Adhemerval Zanella Netto
2023-05-29 21:59                 ` Sergey Bugaev
2023-05-30 11:34                   ` Adhemerval Zanella Netto
2023-05-30  7:41         ` Florian Weimer
2023-05-30  9:07           ` Sergey Bugaev
2023-05-30  9:50             ` Florian Weimer
2023-05-30 11:35               ` Adhemerval Zanella Netto
2023-05-30  8:09 ` [PATCH v2 0/3] fcntl fortification Florian Weimer
2023-05-30 10:46   ` Sergey Bugaev
2023-05-30 11:08     ` Florian Weimer
2023-05-30 11:34       ` Sergey Bugaev
2023-05-30 11:50         ` Florian Weimer
2023-05-30 11:51         ` Florian Weimer
2023-05-30 12:15           ` Sergey Bugaev
2023-05-30 12:26             ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1e0168d1-6175-aec2-bf35-f23aaf14e216@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=bugaevc@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).