lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 Jan 2021 16:00:26 -0800 From: Nick Desaulniers <ndesaulniers@...gle.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Will Deacon <will@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Catalin Marinas <catalin.marinas@....com>, Jan Kara <jack@...e.cz>, Minchan Kim <minchan@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Vinayak Menon <vinmenon@...eaurora.org>, Hugh Dickins <hughd@...gle.com>, Android Kernel Team <kernel-team@...roid.com> Subject: Re: [RFC PATCH 4/8] mm: Separate fault info out of 'struct vm_fault' On Fri, Jan 15, 2021 at 1:33 PM Linus Torvalds <torvalds@...ux-foundation.org> wrote: > > On Fri, Jan 15, 2021 at 1:23 AM Will Deacon <will@...nel.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. I don't really understand British humor either, but I assume that's how the language lawyers throw shade on one anothers' standards. Richard is both the WG21 spec editor (C++) and British, IIRC. Apparently, there's a long conversion (behind closed doors; it's the ISO way) going on in regards to the thread Richard has kicked off with them (WG14; C). Moreso on what should happen with the _Atomic qualifier, assignments, and memcpy. So it is still an important thing to nail down the language spec. Note there were also a lot of discussions lately on "where should the volatile qualifier be allowed, or not." http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html https://www.youtube.com/watch?v=KJW_DLaVXIY (2018? ok, maybe not lately. Lately for C) I view this similarly as "where should the const qualifier be allowed, or not." -- Thanks, ~Nick Desaulniers
Powered by blists - more mailing lists