Windows is only targeting little-endian systems which makes life easier (and in any case they trust MSVC to do the right thing) so Windows drivers make much use of them (just look at the driver samples on Microsoft's GitHub page.)

Linux is a little afraid to rely on GCC/Clang doing the right thing and in any case bitfields are underpowered for a system which targets multiple endians. So Linux uses systems of macros instead for dealing with what Windows C uses bitfields. The usual pattern is a system of macros for shifting and masking. This is considerably uglier and easier to make a mess of. It would be a real improvement in quality-of-life if this were not so.

You can also look at Managarm (which benefits from C++ here) for another approach to making this less fraught: https://github.com/managarm/managarm/blob/a698f585e14c0183df...

The only concrete example is:

Accept some non-standard constructs used in Microsoft header files.

In C++ code, this allows member names in structures to be similar to previous types declarations.

    typedef int UOW;
    struct ABC {
      UOW UOW;
    };

The same extension can be enabled with `-fplan9-extensions`, might be more appealing to some!

  struct parent { int a; } p;
  struct child {
    struct parent;
    int b;
  } c;
  void foo(struct parent *);
  foo(&p); // valid of course
  foo(&c); // also valid under plan9 extension, no casting!

> barring any objections from prominent Linux kernel developers or Linus Torvalds himself.

Just like any other patch, is there any reason to think someone would be likely to object here?

His code is so clear, clean, concise, commented it feels divine in comparison to the drivel I subject myself to daily.

"Almost", because -std=gnu11 is already used, so the answer seems to be right there.

You've heard it here first.

What was the saying popular in the old days, Embrace, Extend, Extinguish?