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: Thu, 14 Jan 2021 14:13:48 +0100 From: Lukas Wunner <lukas@...ner.de> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Will Deacon <will@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Arnd Bergmann <arnd@...nel.org>, Russell King - ARM Linux admin <linux@...linux.org.uk>, linux-toolchains@...r.kernel.org, Mark Rutland <mark.rutland@....com>, Theodore Ts'o <tytso@....edu>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Andreas Dilger <adilger.kernel@...ger.ca>, Ext4 Developers List <linux-ext4@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org> Subject: Re: Aarch64 EXT4FS inode checksum failures - seems to be weak memory ordering issues On Tue, Jan 12, 2021 at 09:28:32AM -0800, Linus Torvalds wrote: > On Tue, Jan 12, 2021 at 5:20 AM Lukas Wunner <lukas@...ner.de> wrote: > > > Variable declarations in for-loops is the only one I can think of. I > > > think that would clean up some code (and some macros), but might not > > > be compelling on its own. > > > > Anonymous structs/unions. I used to have a use case for that in > > struct efi_dev_path in include/linux/efi.h, but Ard Biesheuvel > > refactored it in a gnu89-compatible way for v5.7 with db8952e7094f. > > We use anonymous structs/unions extensively and all over the place already. Yes, my apologies, I mixed things up. Back in 2016 when I authored 46cd4b75cd0e, what I wanted to do was include an unnamed "struct efi_generic_dev_path;" in struct efi_dev_path: struct efi_dev_path { struct efi_generic_dev_path; union { struct { u32 hid; u32 uid; } acpi; struct { u8 fn; u8 dev; } pci; }; } __attribute ((packed)); The alternative is to copy-paste the elements of struct efi_dev_path or to give it a name such as "header" (which is what db8952e7094f subsequently did). Both options seemed inelegant to me. However it turns out this feature requires -fms-extensions. It's not part of -std=gnu11. So coming back to topic, yes there doesn't seem to be too much to be gained from moving to -std=gnu11 aside from variable declarations in for-loops. (And it really has to be -std=gnu11 because -std=c11 fails to compile.) Thanks, Lukas
Powered by blists - more mailing lists