From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Nathan Chancellor <nathan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Mike Rapoport <rppt@linux.ibm.com>,
clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] mm/gfp: Add kernel-doc for gfp_t
Date: Fri, 19 Feb 2021 23:15:02 +0100 [thread overview]
Message-ID: <CANiq72mZPUMipvF6+Dft2XgqqbSRTnAA32P2XM9373i_nq4UNg@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOdmNz7PEZGJW5=FaQiWcShYUBMeo--_JS6JU94bUN9HagQ@mail.gmail.com>
On Fri, Feb 19, 2021 at 10:45 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> That said, I'm fine disabling this warning; there's a separate error
> for redefining a typedef to a different underlying type. That's
> what's useful IMO, this one really is not.
>
> This warning doesn't really provide any value to us in the kernel; I
> would guess the intent was to be helpful to code expected to be
> portable across different -std=*
It seems it would also be useful to sport unintended cases, e.g.:
- Collisions on short identifiers (that by chance typedef to the same type).
- Copy-pasting and forgetting to remove the original definition
(i.e. it should have be cut-pasting instead).
- Double inclusion of headers (with missing or broken #ifdef guards).
Those may be providing value in the kernel. In particular, if we don't
see any warning at the moment, it means those cases are not happening
now anywhere, so we would be weakening things.
Having said that, I don't see the original patch, so perhaps I am
missing something.
Cheers,
Miguel
next prev parent reply other threads:[~2021-02-19 22:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-15 20:49 [PATCH] mm/gfp: Add kernel-doc for gfp_t Matthew Wilcox (Oracle)
2021-02-15 21:07 ` Mike Rapoport
2021-02-19 19:55 ` Nathan Chancellor
2021-02-19 20:54 ` Matthew Wilcox
2021-02-19 21:45 ` Nick Desaulniers
2021-02-19 22:15 ` Miguel Ojeda [this message]
2021-02-19 22:49 ` Nick Desaulniers
2021-02-20 9:43 ` Miguel Ojeda
2021-02-22 17:04 ` Nick Desaulniers
2021-02-22 17:16 ` Matthew Wilcox
2021-02-22 17:34 ` Nick Desaulniers
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=CANiq72mZPUMipvF6+Dft2XgqqbSRTnAA32P2XM9373i_nq4UNg@mail.gmail.com \
--to=miguel.ojeda.sandonis@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=clang-built-linux@googlegroups.com \
--cc=linux-mm@kvack.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=rppt@linux.ibm.com \
--cc=willy@infradead.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 NNTP newsgroup(s).