Re: Aarch64 EXT4FS inode checksum failures - seems to be weak memory ordering issues
From: Lukas Wunner <lukas@wunner.de>
Date: 2021-01-14 13:23:54
Also in:
linux-ext4, lkml
On Tue, Jan 12, 2021 at 09:28:32AM -0800, Linus Torvalds wrote:
On Tue, Jan 12, 2021 at 5:20 AM Lukas Wunner [off-list ref] wrote:quoted
quoted
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