Note that these are not the Microsoft "C Extensions", but the "Microsoft C Extensions" of the GNU Compiler Toolchain. I doubt MSVC supports -fms-extensions.
If it's about "prettier code" then I think a number one candidate would be making bitfields more viable for use. It could make driver code much cleaner and safer.
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.
PowerPC "supports" both, but I believe it's typically run in big endian mode. Same with MIPS AFAIK.
(Mini rant: CPU people seem to think that you can avoid endianness issues by just supporting both little and big endian, not realizing the mess they're creating higher up the stack. The OS's ABI needs to be either big endian or little endian. Switchable endianness at runtime solves nothing and causes a horrendous mess.)
You could actually support both at runtime with both ABIs being available. This is done routinely on x86_64 with x86 ABI for compatibility (both sets of system libraries are installed), for a while I used to run 3 ABIs (including x32 - the 64bit with short pointers) for memory savings with interpreted languages.
IRIX iirc supported all 4 variants of MIPS; HP-UX did something weird too! I’d say for some computations one or the other endianness is preferred and can be switched at runtime.
Back in the day it also saved on a lot of network stack overheads - the kernel can switch endianness at will, and did so.
Now the reasoning isn't present in the patch but it probably is because they want step increments and -fms-extensions is a small-ish first step. Maybe -fplan9-extensions could make sense later, in a few years.
Can you confirm whether or not anonymous member structures originated with the Plan 9 C compiler? I know I first learned of them from the Plan 9 compiler documentation, but that was long after they were already in GCC. I can't find when they were added to Microsoft's C compiler, but I'm guessing GCC's "-fms-extensions" flag is so named simply because it originated as a compatibility option for the MinGW project, and doesn't by itself imply they were a Microsoft invention. GCC gained -fms-extensions and anonymous member structures in 1999, and MinGW is first mentioned in GCC in 1997. (Which maybe suggests Microsoft C gained anonymous structure members between 1997 and 1999?)
Relatedly, do you know if anonymous member unions originate with C++, Plan 9 C, or elsewhere?
Huh. I thought the article was vague on what exactly these extensions permit, so I'd thought I'd look up the GNU documentation. Surprisingly, it [1] was rather vague too!
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.
The important one is "Unnamed Structure and Union Fields"[1], in particular unnamed structs and union fields without a tag.
ISO C11 and onward allows for this:
struct {
int a;
union {
int b;
float c;
};
int d;
} foo;
In the above, you can access b as foo.b. In ISO C11, the inner struct/union must be defined without a tag. Meaning that this is invalid:
struct {
int a;
union bar {
int b;
float c;
};
int d;
} foo;
As is this:
union bar {
int b;
float c;
};
struct {
int a;
union bar;
int d;
} foo;
-fms-extensions makes both of the above valid. You might be wondering why this is uesful. The most common use is for nicer struct embedding/pseudo-inheritance:
> Some implementations have permitted anonymous member-structures and -unions in extended C to contain tags, which allows tricks such as the following.
struct point { float x, y, z; };
struct location {
char *name;
struct point; // inheritance in extended C, but
// forward declaration in C++
};
> This proposal does not support that practice, for two reasons. First, it introduces a gratuitous difference between C and C++, since C++ implementations must treat the declaration of point within location as a forward reference to the type location::point rather than a definition of an unnamed member. Second, this feature does not seem to be used widely in applications, perhaps because it compiles differently in extended C vs. C++.
Extremely tangential: I maintain some of Rasmus's code. I've never met the man. I'd heard that kernel programmers were the "rockstar programmers of rockstar programmers", but I only grok it now.
His code is so clear, clean, concise, commented it feels divine in comparison to the drivel I subject myself to daily.
Note that these are not the Microsoft "C Extensions", but the "Microsoft C Extensions" of the GNU Compiler Toolchain. I doubt MSVC supports -fms-extensions.
If it's about "prettier code" then I think a number one candidate would be making bitfields more viable for use. It could make driver code much cleaner and safer.
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...
Does anyone big endian anymore?
PowerPC "supports" both, but I believe it's typically run in big endian mode. Same with MIPS AFAIK.
(Mini rant: CPU people seem to think that you can avoid endianness issues by just supporting both little and big endian, not realizing the mess they're creating higher up the stack. The OS's ABI needs to be either big endian or little endian. Switchable endianness at runtime solves nothing and causes a horrendous mess.)
You could actually support both at runtime with both ABIs being available. This is done routinely on x86_64 with x86 ABI for compatibility (both sets of system libraries are installed), for a while I used to run 3 ABIs (including x32 - the 64bit with short pointers) for memory savings with interpreted languages.
IRIX iirc supported all 4 variants of MIPS; HP-UX did something weird too! I’d say for some computations one or the other endianness is preferred and can be switched at runtime.
Back in the day it also saved on a lot of network stack overheads - the kernel can switch endianness at will, and did so.
Linux has mostly transitioned to little endian on PowerPC. AIX remains big endian.
z/Processor is big endian
> though some may feel the wrong way around Microsoft C behavior being permitted
The same extension can be enabled with `-fplan9-extensions`, might be more appealing to some!
-fplan9-extensions adds even more, it is not an alias: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Unnamed-Fields...
One of the link of past discussions was from Apr 2018 and discusses it. At that time GCC -fplan9-extensions support was too recent (gcc-4.6) to be considered. https://lore.kernel.org/lkml/20180419152817.GD25406@bombadil...
Now the reasoning isn't present in the patch but it probably is because they want step increments and -fms-extensions is a small-ish first step. Maybe -fplan9-extensions could make sense later, in a few years.
It certainly seems to me that using this would eliminate 75% or so of the objections to it.
For this use case, at least, it feels like a CS version of racism. MSFT is bad, so no MSFT.
It largely clears up an idiosyncrasy from the evolution of C.
(but, as someone that briefly worked on plan9 in 1995/96, I like your idea :)
Can you confirm whether or not anonymous member structures originated with the Plan 9 C compiler? I know I first learned of them from the Plan 9 compiler documentation, but that was long after they were already in GCC. I can't find when they were added to Microsoft's C compiler, but I'm guessing GCC's "-fms-extensions" flag is so named simply because it originated as a compatibility option for the MinGW project, and doesn't by itself imply they were a Microsoft invention. GCC gained -fms-extensions and anonymous member structures in 1999, and MinGW is first mentioned in GCC in 1997. (Which maybe suggests Microsoft C gained anonymous structure members between 1997 and 1999?)
Relatedly, do you know if anonymous member unions originate with C++, Plan 9 C, or elsewhere?
Archives of published MS SDKs show they were using the feature in NT 3.1's public headers in 1993, so it's at least that old.
https://archive.org/details/win32-sdk-final-release-nt-31
Do you have references to objections? I couldn't find any on the lkml threads.
Huh. I thought the article was vague on what exactly these extensions permit, so I'd thought I'd look up the GNU documentation. Surprisingly, it [1] was rather vague too!
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.
[1]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#in...The important one is "Unnamed Structure and Union Fields"[1], in particular unnamed structs and union fields without a tag.
ISO C11 and onward allows for this:
In the above, you can access b as foo.b. In ISO C11, the inner struct/union must be defined without a tag. Meaning that this is invalid: As is this: union bar { int b; float c; }; -fms-extensions makes both of the above valid. You might be wondering why this is uesful. The most common use is for nicer struct embedding/pseudo-inheritance: [1]: https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.htmlAm I right to think this is really unobjectionable, and is only being objected to because MS "invented" it?
border-box says hi [1]
[1]: https://www.paulirish.com/2012/box-sizing-border-box-ftw/
(Funnily, tables always default to border-box, so the objections in CSS standardization at the time is really silly.)
Why is this still not standardized?
The original proposal at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1406.pdf explains why.
> Some implementations have permitted anonymous member-structures and -unions in extended C to contain tags, which allows tricks such as the following.
> This proposal does not support that practice, for two reasons. First, it introduces a gratuitous difference between C and C++, since C++ implementations must treat the declaration of point within location as a forward reference to the type location::point rather than a definition of an unnamed member. Second, this feature does not seem to be used widely in applications, perhaps because it compiles differently in extended C vs. C++.A really good example of it is in this lore thread here [1]. He explains it better than me so I'll just link it here
[1]: https://lore.kernel.org/lkml/200706301813.58435.agruen@suse....
Tinfoil Hat Time: Microsoft is dropping windows and OS development, MS/Linux in the future.
You've heard it here first.
Extremely tangential: I maintain some of Rasmus's code. I've never met the man. I'd heard that kernel programmers were the "rockstar programmers of rockstar programmers", but I only grok it now.
His code is so clear, clean, concise, commented it feels divine in comparison to the drivel I subject myself to daily.
Mind linking to some example(s)? Would love to see :-)
This really speaks more to the inadequacy of C rather than Microsoft.
Microsoft "embrace, extend and takeover" comes to mind here. Caveat emptor.
Compiler extensions have existed ever since C was standardized. I don't like Microsoft either but this really isn't a case of them acting malicious.
Isn't this a case of Evil Linux embracing M$ in order to extinguish it?