8 ms·

The Linux Kernel Looks to “Bite the Bullet” in Enabling Microsoft C Extensions

136 points by keyle 11mo ago

deleted 11mo ago
[deleted]
unwind 11mo ago
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. typedef int UOW; struct ABC { UOW UOW; }; [1]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-fms-extensions https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#in...
- messe 11mo ago
  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: struct parent { int i; void *p; }; void parent_do_something(struct parent *p); struct child { struct parent; const char *s; }; struct child *c; struct parent *p = (struct child *)c; // valid parent_do_something(p); c.i++; // valid [1]: https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html
  - creshal 11mo ago
    Why is this still not standardized?
    - wahern 11mo ago
      The original proposal at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1406.pdf 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. 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++.
      - avadodin 11mo ago
        If C and C++ standardization had included both languages since the beginning, compatibility could have been a thing but it didn't so the languages have diverged since C-with-classes. I don't understand why the C standard has to get bogged down with bizarro-world-C restrictions from C++. It's 2025, people have to give up on C/C++.
        IsTom 11mo ago
        C++ routinely includes C headers and this would affect that. I think most things valid in C, but not C++ don't affect declarations.
        johnisgood 11mo ago
        > It's 2025, people have to give up on C/C++. No, people should not give up on C. ??? You do realize there are a lot of projects written in C, right? Including Linux and most of its programs / utilities that you may be using. I have new projects written in C, too, and you can do a lot to check for potential bugs using various flags to GCC / Clang, among other things like cppcheck and the rest. No, people should not give up on C. C is really good to know, for many reasons... even if you are not going to use it.
- arguflow 11mo ago
  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.de/ https://lore.kernel.org/lkml/200706301813.58435.agruen@suse....
fuhsnn 11mo ago
> 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!
- tleb_ 11mo ago
  -fplan9-extensions adds even more, it is not an alias: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Unnamed-Fields.html 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.infradead.org/ 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.
  - molticrystal 11mo ago
    Plan 9 extensions would only require enough examples to justify and might not take years. Though your taking years assessment would be right if there's a dearth of kernel spots to add up where automatic pointer conversion for anonymous fields, or using the typedef name to access them, offer some improvement, not necessarily even a huge improvement. Since with the Microsoft extension, it was just waiting until enough examples were woven into the discussion to overcome the back and forth that was preventing "biting the bullet".
- Quarrel 11mo ago
  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 :)
  - tleb_ 11mo ago
mrlonglong 11mo ago
[flagged]
- pezgrande 11mo ago
  Isn't this a case of Evil Linux embracing M$ in order to extinguish it?
- juliangmp 11mo ago
  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.
  - moomin 11mo ago
    Grace Hopper was big on preventing the use of COBOL compiler extensions. She talks about it on the declassified NSA lecture.
dingnuts 11mo ago
[dead]
MangoToupe 11mo ago
This really speaks more to the inadequacy of C rather than Microsoft.
netbsdusers 11mo ago
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/a698f585e14c0183df39ebf2a1d6370358bbf025/drivers/usb/hcds/xhci/src/spec.hpp#L104-L120 https://github.com/managarm/managarm/blob/a698f585e14c0183df...
- reactordev 11mo ago
  Does anyone big endian anymore?
  - mort96 11mo ago
    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.)
    - fredoralive 11mo ago
      Linux has mostly transitioned to little endian on PowerPC. AIX remains big endian.
      - mghackerlady 11mo ago
yinkindog 11mo ago
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.
- piotrpdev 11mo ago
  Mind linking to some example(s)? Would love to see :-)
1718627440 11mo ago
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.
nurettin 11mo ago
Tinfoil Hat Time: Microsoft is dropping windows and OS development, MS/Linux in the future. You've heard it here first.
- 1718627440 11mo ago
  But will it be Win32/Linux or GNU/NT ?
  - bmacho 11mo ago
    Knowing Microsoft, it will be both. That is, ship every runtime ever provided. Win32, Linux kernel, GNU and NT kernel, all of them. Ms already ships a Linux kernel, and msys2/git bash, and they won't stop doing it.
    - 1718627440 11mo ago
      > Ms already ships ... msys2/git bash That is an independent FOSS project to my knowledge. > Knowing Microsoft, it will be both. Possible. But then when they are content with both the kernel and the userspace, why should they switch at all? The must be wanting to replace some maintenance burden, otherwise they won't do it.
      - bmacho 11mo ago
        You are right, Git for Windows is by random people. I don't know why I was so sure that it was a Microsoft product. > Possible. But then when they are content with both the kernel and the userspace, why should they switch at all? A lot of developer tools only work on Linux. That's why they provide WSL2, a Linux kernel.
        dspillett 11mo ago
        > I don't know why I was so sure that it was a Microsoft product. It is shipped with VS. If this is your only interaction with it then that is an easy assumption to make.
dooglius 11mo ago
It seems like the article is trying to suggest there is some drama here when the change is completely anodyne. > 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?
dataflow 11mo ago
You almost have to wonder whether the past decisions to avoid this were based on the merits of the situation, or just based on the default hate of Microsoft. If it had been called "-fgnu-extensions" instead, would it have taken this long to enable? "Almost", because -std=gnu11 is already used, so the answer seems to be right there.
jmclnx 11mo ago
Well since trough the Linux Foundation, Microsoft owns Linux along with a few others, no surprise to me. What was the saying popular in the old days, Embrace, Extend, Extinguish?
- creatonez 11mo ago
  This has nothing to do with compiling Linux with Microsoft compilers. Or anything to do with Microsoft at all. So... no. "Embrace, Extend, Extinguish" makes no sense in this context. The entire story here is "they enabled an old compiler quirk in GCC to have a bit more flexibility".
- jamesnorden 11mo ago
  Nice Slashdot comment from 2004.
teo_zero 11mo ago
I would have liked the extension named after Plan9 more than this one after Microsoft. Not based on any ideology, mind you, but rather because the former is more powerful and allows this: 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!

136 points by keyle 11mo ago

deleted 11mo ago

[deleted]

unwind 11mo ago

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. typedef int UOW; struct ABC { UOW UOW; }; [1]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-fms-extensions https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#in...

messe 11mo ago
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: struct parent { int i; void *p; }; void parent_do_something(struct parent *p); struct child { struct parent; const char *s; }; struct child *c; struct parent *p = (struct child *)c; // valid parent_do_something(p); c.i++; // valid [1]: https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html
- creshal 11mo ago
  Why is this still not standardized?
  - wahern 11mo ago
    The original proposal at https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1406.pdf 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. 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++.
    - avadodin 11mo ago
      If C and C++ standardization had included both languages since the beginning, compatibility could have been a thing but it didn't so the languages have diverged since C-with-classes. I don't understand why the C standard has to get bogged down with bizarro-world-C restrictions from C++. It's 2025, people have to give up on C/C++.
      - IsTom 11mo ago
        C++ routinely includes C headers and this would affect that. I think most things valid in C, but not C++ don't affect declarations.
      - johnisgood 11mo ago
        > It's 2025, people have to give up on C/C++. No, people should not give up on C. ??? You do realize there are a lot of projects written in C, right? Including Linux and most of its programs / utilities that you may be using. I have new projects written in C, too, and you can do a lot to check for potential bugs using various flags to GCC / Clang, among other things like cppcheck and the rest. No, people should not give up on C. C is really good to know, for many reasons... even if you are not going to use it.
arguflow 11mo ago
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.de/ https://lore.kernel.org/lkml/200706301813.58435.agruen@suse....

fuhsnn 11mo ago

> 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!

tleb_ 11mo ago
-fplan9-extensions adds even more, it is not an alias: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Unnamed-Fields.html 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.infradead.org/ 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.
- molticrystal 11mo ago
  Plan 9 extensions would only require enough examples to justify and might not take years. Though your taking years assessment would be right if there's a dearth of kernel spots to add up where automatic pointer conversion for anonymous fields, or using the typedef name to access them, offer some improvement, not necessarily even a huge improvement. Since with the Microsoft extension, it was just waiting until enough examples were woven into the discussion to overcome the back and forth that was preventing "biting the bullet".
Quarrel 11mo ago
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 :)
- tleb_ 11mo ago

mrlonglong 11mo ago

[flagged]

pezgrande 11mo ago
Isn't this a case of Evil Linux embracing M$ in order to extinguish it?
juliangmp 11mo ago
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.
- moomin 11mo ago
  Grace Hopper was big on preventing the use of COBOL compiler extensions. She talks about it on the declassified NSA lecture.

dingnuts 11mo ago

[dead]

MangoToupe 11mo ago

This really speaks more to the inadequacy of C rather than Microsoft.

netbsdusers 11mo ago

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/a698f585e14c0183df39ebf2a1d6370358bbf025/drivers/usb/hcds/xhci/src/spec.hpp#L104-L120 https://github.com/managarm/managarm/blob/a698f585e14c0183df...

reactordev 11mo ago
Does anyone big endian anymore?
- mort96 11mo ago
  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.)
  - fredoralive 11mo ago
    Linux has mostly transitioned to little endian on PowerPC. AIX remains big endian.
    - mghackerlady 11mo ago

yinkindog 11mo ago

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.

piotrpdev 11mo ago
Mind linking to some example(s)? Would love to see :-)

1718627440 11mo ago

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.

nurettin 11mo ago

Tinfoil Hat Time: Microsoft is dropping windows and OS development, MS/Linux in the future. You've heard it here first.

1718627440 11mo ago
But will it be Win32/Linux or GNU/NT ?
- bmacho 11mo ago
  Knowing Microsoft, it will be both. That is, ship every runtime ever provided. Win32, Linux kernel, GNU and NT kernel, all of them. Ms already ships a Linux kernel, and msys2/git bash, and they won't stop doing it.
  - 1718627440 11mo ago
    > Ms already ships ... msys2/git bash That is an independent FOSS project to my knowledge. > Knowing Microsoft, it will be both. Possible. But then when they are content with both the kernel and the userspace, why should they switch at all? The must be wanting to replace some maintenance burden, otherwise they won't do it.
    - bmacho 11mo ago
      You are right, Git for Windows is by random people. I don't know why I was so sure that it was a Microsoft product. > Possible. But then when they are content with both the kernel and the userspace, why should they switch at all? A lot of developer tools only work on Linux. That's why they provide WSL2, a Linux kernel.
      - dspillett 11mo ago
        > I don't know why I was so sure that it was a Microsoft product. It is shipped with VS. If this is your only interaction with it then that is an easy assumption to make.

dooglius 11mo ago

It seems like the article is trying to suggest there is some drama here when the change is completely anodyne. > 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?

dataflow 11mo ago

You almost have to wonder whether the past decisions to avoid this were based on the merits of the situation, or just based on the default hate of Microsoft. If it had been called "-fgnu-extensions" instead, would it have taken this long to enable? "Almost", because -std=gnu11 is already used, so the answer seems to be right there.

jmclnx 11mo ago

Well since trough the Linux Foundation, Microsoft owns Linux along with a few others, no surprise to me. What was the saying popular in the old days, Embrace, Extend, Extinguish?

creatonez 11mo ago
This has nothing to do with compiling Linux with Microsoft compilers. Or anything to do with Microsoft at all. So... no. "Embrace, Extend, Extinguish" makes no sense in this context. The entire story here is "they enabled an old compiler quirk in GCC to have a bit more flexibility".
jamesnorden 11mo ago
Nice Slashdot comment from 2004.

teo_zero 11mo ago

I would have liked the extension named after Plan9 more than this one after Microsoft. Not based on any ideology, mind you, but rather because the former is more powerful and allows this: 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!