From: Linus Torvalds <torvalds@linux-foundation.org>
To: Will Deacon <will@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jan Kara <jack@suse.cz>, Minchan Kim <minchan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Vinayak Menon <vinmenon@codeaurora.org>,
Hugh Dickins <hughd@google.com>,
Android Kernel Team <kernel-team@android.com>
Subject: Re: [RFC PATCH 4/8] mm: Separate fault info out of 'struct vm_fault'
Date: Fri, 15 Jan 2021 13:32:57 -0800 [thread overview]
Message-ID: <CAHk-=wjWQFSZci+By4wXAEx6EDH4nss7tf5QimQpF53rnHa7Wg@mail.gmail.com> (raw)
In-Reply-To: <20210115092313.GA13700@willie-the-truck>
On Fri, Jan 15, 2021 at 1:23 AM Will Deacon <will@kernel.org> wrote:
>
> Hmm. The feedback on the clang bug suggests that GCC is the one in the
> wrong here (although the argument is based on C11 and I haven't trawled
> through the standards to see how this has evolved):
Oh well.
That writing is absolutely the _worst_ kind of weaselwording standards
language reading, trying to make excuses for bad behavior by basically
depending on "this language is unclear", and trying to say that the
buggy behavior is required by C11.
What a disappointment.
Absolutely nothing in the quoted C11 language says to me what that bug
entry claims it says.
The argument seems to hinge on
"The members of an anonymous structure or union are considered to
be members of the containing structure or union"
and then it makes the completely uncalled-for leap that that means
that because it was "int" in the const struct, it must be "int" in the
containing structure too.
Which is complete BS, and doesn't follow logically _or_ grammatically.
It would be a "member of the containing structure" even with the
"const" qualifier, so the argument they make is just inane.
In fact, the _other_ sentence they quote clearly points to this being
just a clang bug:
"A modifiable lvalue is [...] if it is a structure or union, does not
have any member (including, recursively, any member or element of all
contained aggregates or unions) with a const- qualified type"
and clearly this recursively is an element with a const-qualified
recursive struct.
Whatever. It's one of those "read the documentation squint-eyed to
avoid doing the right thing" arguments.
It's not worth arguing with people like that, and let's just ignore
the clang bug here.
Linus
next prev parent reply other threads:[~2021-01-15 21:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 17:59 [PATCH v3 0/8] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag Will Deacon
2021-01-14 17:59 ` [PATCH v3 1/8] mm: Cleanup faultaround and finish_fault() codepaths Will Deacon
2021-02-09 20:24 ` Guenter Roeck
2021-02-10 11:44 ` Will Deacon
2021-02-10 14:57 ` Guenter Roeck
2021-01-14 17:59 ` [PATCH v3 2/8] mm: Allow architectures to request 'old' entries when prefaulting Will Deacon
2021-01-14 17:59 ` [PATCH v3 3/8] arm64: mm: Implement arch_wants_old_prefaulted_pte() Will Deacon
2021-01-14 17:59 ` [RFC PATCH 4/8] mm: Separate fault info out of 'struct vm_fault' Will Deacon
2021-01-14 18:16 ` Linus Torvalds
2021-01-14 19:00 ` Will Deacon
2021-01-14 19:09 ` Linus Torvalds
2021-01-14 19:41 ` Will Deacon
2021-01-14 20:09 ` Nick Desaulniers
2021-01-14 21:11 ` Linus Torvalds
2021-01-15 9:23 ` Will Deacon
2021-01-15 21:32 ` Linus Torvalds [this message]
2021-01-20 0:00 ` Nick Desaulniers
2021-01-14 17:59 ` [RFC PATCH 5/8] mm: Pass 'address' to map to do_set_pte() and drop FAULT_FLAG_PREFAULT Will Deacon
2021-01-14 18:17 ` Linus Torvalds
2021-01-15 10:24 ` Will Deacon
2021-01-14 17:59 ` [RFC PATCH 6/8] mm: Avoid modifying vmf.info.address in __collapse_huge_page_swapin() Will Deacon
2021-01-14 17:59 ` [RFC PATCH 7/8] mm: Use static initialisers for 'info' field of 'struct vm_fault' Will Deacon
2021-01-14 17:59 ` [RFC PATCH 8/8] mm: Mark 'info' field of 'struct vm_fault' as 'const' Will Deacon
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='CAHk-=wjWQFSZci+By4wXAEx6EDH4nss7tf5QimQpF53rnHa7Wg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=kernel-team@android.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=vinmenon@codeaurora.org \
--cc=will@kernel.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).