The Linux Kernel Looks to “Bite the Bullet” in Enabling Microsoft C Extensions
Mood
thoughtful
Sentiment
mixed
Category
tech
Key topics
Linux kernel
C programming language
Microsoft
The Linux kernel is considering enabling Microsoft C extensions, sparking a discussion about the implications and motivations behind this decision, with some commenters weighing in on the technical merits and others raising concerns about Microsoft's influence.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
15m
Peak period
62
Day 1
Avg / period
46.5
Based on 93 loaded comments
Key moments
- 01Story posted
11/10/2025, 8:09:31 AM
9d ago
Step 01 - 02First comment
11/10/2025, 8:24:08 AM
15m after posting
Step 02 - 03Peak activity
62 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
11/12/2025, 7:44:11 AM
7d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
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;
};
ISO C11 and onward allows for this:
struct {
int a;
union {
int b;
float c;
};
int d;
} foo;
struct {
int a;
union bar {
int b;
float c;
};
int d;
} foo;
struct {
int a;
union bar;
int d;
} foo;
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
> 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++
};
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++.
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.
The same tricks are also enabled in the plan9 extensions, but enabling plan9 extensions also enables a bunch of other tricks and those changes landed later than the Microsoft ones. Aiming to enable plan9 instead probably could've saved the Linux kernel half a decade of "Microsoft bad" comments, though.
Still, it's not the official C standard, but a specific flavour of C11, so my point still stands.
[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.)
struct parent *p = (struct child *)c; // valid
[1]: https://lore.kernel.org/lkml/200706301813.58435.agruen@suse....
The same extension can be enabled with `-fplan9-extensions`, might be more appealing to some!
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.
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".
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 :)
Relatedly, do you know if anonymous member unions originate with C++, Plan 9 C, or elsewhere?
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...
(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.)
Otherwise you don't need the other endian to confirm it?
Or are you saying to test their software before it goes out to big endian devices, which doesn't answer the question as to why someone would want to use it on those end devices?
I don't know whether this logic applies to this specific sort of bug, but there is a long history of bugs that "don't matter" combining with other bugs to become something that matters. Therac-25 was a bug that didn't matter on the hardware it was developed for, but then the software that "worked fine" got repurposed for another hardware platform and people died. If there's an easy way to identify an entire class of bugs it seems like a good idea to do it.
AFAIK, this is probably the easiest way to test BE on hardware (if you need that for some reason) - NetBSD on a Raspberry Pi running in BE mode is easy to use. (EDIT: Actually the more important thing is that it's cheap and easy to acquire)
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.
Because that's how 32-bit x86 support is handled. There are two variants of every library. These days, Linux distros don't even provide 32-bit libraries by default, and Ubuntu has even moved to remove most of the 32-bit libraries from their repositories in recent years.
Apple removed 32-bit x86 support entirely a few years back so that they didn't have to ship two copies of all libraries anymore.
What you're proposing as a way to support both little and big endian ABIs is the old status quo that the whole world has been trying (successfully) to move away from for the past decade due to its significant downsides.
And this is to say nothing of all the protocols out there which are intended for communication within one computer and therefore assume native endianness.
Big advantage of the “old ways” was the cohesion of software versions within a heterogenous cluster. In a way I caught the tail end of that with phasing out of MIT Athena (which at the time was very heterogeneous on the OS and architecture side) - but the question is, well, why.
Our industry is essentially a giant loop of centralizing and decentralizing, with advantages in both, and propagation delays between “new ideas” and implementation. Nothing new, all the economy is necessarily cyclic so why not this.
I’d argue that in the era of inexpensive hardware (again) and heterogenous edge compute, being able to run a single binary across all possible systems will again be advantageous for distribution. Some of that is the good old cosmopolitan libc, some of that is just a broad failure of /all/ end-point OS (which will brood its own consequences) - Windows 11, OSX, Androids etc..
This had the advantage that one, networked root filesystem could boot both M68K and PA-RISC, or both o32 and n64 MIPS ABIs, and I’m pretty sure this would’ve worked happily on IA64 (again, from the same FS!)
The notion of “local storage boot” was relatively new and expensive in the Unix-land; single-user computing was alien, everyone was thin-clienting in. And it was trivial to create a boot server in which 32bit and 64bit and even other-arch (!) software versions were in perfect sync.
Nothing in current Linux actually forbids that. With qemu binfmt you can easily have one host and multiple userland architectures; and it sometimes even works OK for direct kernel syscalls.
All essentially aiming for a very different world, one that still runs behind the scenes in many places. The current Linux is dominated both by the “portable single-user desktop” workloads (laptops), and by essentially servers running JIT-interpreted language fast time to market startups. Which pushed the pendulum in the direction of VMs, containerization and essentially ephemeral OS. That’s fine for the stated usecase, but there are /still/ tons of old usecases of POS terminals actually using up a console driver off a (maybe emulated) old Unix. And a viable migration path for many of those might well be multi-endian (but often indeed emulated) something.
Even early Windows NT handled multi-architecture binaries and could’ve run fat binaries! We only settled on x86 in mid 1990s!
68k+PPC 1994-2007, PPC32+PPC64 2003-2008, PPC+x86 2006-2008, x86+x64 2007-2019, x64+ARM 2021-2028(announced).
[1]: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6W...
Supporting big endian for big-endian-only CPUs does not fall into that category.
> Oh Christ. Is somebody seriously working on BE support in 2025?
Followed by Eric:
> And as someone who works on optimized crypto and CRC code, the arm64 big endian kernel support has always been really problematic. It's rarely tested, and code that produces incorrect outputs on arm64 big endian regularly gets committed and released. It sometimes gets fixed, but not always; currently the arm64 SM3 and SM4 code produces incorrect outputs on big endian in mainline
BE support is unambiguously best-effort (which is none in some cases).
No, the Kernel does not take BE seriously. Not sure why I have to quote from the mailing list when the URL was a significant portion of my comment text - it directly contradicts your assertion on multiple fronts.
BE support in ARM is poor because ARM is primarily a LE architecture and almost nobody needs ARM BE.
There may have been others in the NE format. Also pretty sure the older power pc mac 7/8 machines were big endian.
But why? This sounds like a company that should have been a dissertation.
There are definitely companies out there who want to run "wrong endian" configs -- traditionally this was "I have a big endian embedded networking device and I want to move away from a dying architecture (e.g. MIPS or PPC) but I really don't want to try to find all the places in my enormous legacy codebase where we accidentally or deliberately assumed big endian".
Personally I'm not in favour of having the niche usecase tail wag the general toolchain dog, and I think that's the sentiment behind Linus's remarks.
- memory bandwidth limits: for each packet, you do pkt NIC -> RAM, headers RAM -> cache, process, cache -> RAM, pkt RAM -> NIC. Oh and that's assuming you're only looking at headers for e.g. routing; performing DPI will have the whole packet do RAM -> cache.
- processing limits: route lookup, ACL evaluation, checksumming, etc
- branch predictor limits: if you have enough mixed traffic, the branch predictor will be basically useless. Even performing RPS will not save you if you have enough streams
So yeah, endianness is a non-issue processing-wise. So more so that one of the most expensive operations (checksumming) can be done on a LE CPU without swapping the byte order.
char * input = receive_data();
struct deserialized * decoded = (struct deserialized *)input; // zero cost deserialization
Of course this can only work if an implementation tells you exactly what the memory layout of 'struct deserialized' and all the data types in it are.
Btw, ordering is somewhat more defined than packing, in that the usual forward/reverse/little/big-endian shenanigans are OK. But relative ordering of each field is always preserved by the C standard.
His code is so clear, clean, concise, commented it feels divine in comparison to the drivel I subject myself to daily.
You've heard it here first.
Ms already ships a Linux kernel, and msys2/git bash, and they won't stop doing it.
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.
> 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.
In addition Git for Windows and MSYS2 are different projects, but Git for Windows ships a strapped down version of MSYS2, which is a bit annoying once you want to use anything else, as now you have two (incompatible) versions of MSYS2 around. I would like if they would backport Git for Windows into MSYS2 proper.
It is shipped with VS. If this is your only interaction with it then that is an easy assumption to make.
> That is an independent FOSS project to my knowledge
Yes, but they do ship it as part of VS: https://random.spillett.net/stuff/tmp/setup_UYht2mgWnW.png
> The must be wanting to replace some maintenance burden
I'm sure they'd love to drop Windows as-is, certainly on the desktop, and let others have that burden (moving Gamers to a walled garden via XBox, let Apple and Linux have all the hardware and user support issues on desktops/laptops and phones, etc.), but momentum and backwards compatibility are massive problems and even ignoring those dropping Windows would just be too embarrassing.
Windows isn't the cash-cow it once was, it might even be a cost depending on how you massage the figures, the bread-winners for MS are currently: Azure, SQL Server, and Office. Office itself is part of the collection of things that would hold back a desktop OS exit for MS: there isn't a full port for any other OS and the online version is not feature-complete.
Sure, but developing both Win32/Linux and GNU/NT, means they would not get rid of anything. They need to keep the userspace API, so maybe they would favor Win32/Linux over GNU/NT. But then why should they get rid of the kernel, which is the least of their problems, isn't held back by API compatibility, is widely praised for its quality and supports a lot of things, which userspace doesn't. (fork, symlinks, etc.) What is the benefit of Win32/Linux over Win32/NT for Microsoft?
The alternative doesn't make sense either. There is no point in integrating their kernel into a different OS, when the result only is a different flavor of that OS. Why should anyone use GNU/NT over GNU/Linux, when it's still incompatible with all Windows software?
They could massively invest into Wine or an alternative and maybe also implement a shim for kernel modules. Or there could open-source Win32 and wait for it to merge with Wine, so that Win32/Linux becomes viable. Lastly they could spin off Windows OS into its own company and it would become just one of their targets for their software. This would likely also improve Windows, as the OS' main problem is forcing ads and bloatware into it. But why would Microsoft allow that?
-----
Arguable GNU/NT already exists with MSYS2/Cygwin. What they are missing is an OS package manager, integration into the user/process/permission system, a registry shim and a way to force random program installers to install into the FHS.
> but momentum and backwards compatibility are massive problems
That, and loss of face.
> Lastly they could spin off Windows OS into its own company and it would become just one of their targets for their software.
That is an option that hadn't occurred to me, and it is closer to what I was meaning with “drop Windows as-is” then “drop parts of windows and replace with GNU or Linux”: drop windows desktop full-stop, concentrate on milking Azure platform income, Office subscriptions, and SQL Server licenses. I wouldn't envisage they'd drop everything, at least not immediately, as keeping a server subset alive to support more minor products like Exchange might be more practical than quickly porting them.
> This would likely also improve Windows, as the OS' main problem is forcing ads and bloatware into it. But why would Microsoft allow that?
Not quite sure what you are meaning there, but wrt ads and bloatware that boat has already sailed and MS is actively doing it, not just allowing it.
Exactly the opposite. A standalone Windows company wouldn't have a reason to force Copilot, Cortana, a Microsoft account, etc., since their only objective is to develop an OS. "But why would Microsoft allow that?" = "Why would give up that power over the OS?"
> That, and loss of face.
Right now. But when people got used to the OS being shitty, nobody would be sad if it's gone. Maybe that's the plot with Windows 11 and why they already partially have given up with backwards compatibility. :-)
What was the saying popular in the old days, Embrace, Extend, Extinguish?
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".
"Almost", because -std=gnu11 is already used, so the answer seems to be right there.
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?
4 more comments available on Hacker News
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.