The Linux Kernel Looks To 'Bite the Bullet' In Enabling Microsoft C Extensions (phoronix.com) 42
Linux kernel developers are moving toward enabling Microsoft C Extensions (-fms-extensions) by default in Linux 6.19, with Linus Torvalds signaling no objection. While some dislike relying on Microsoft-style behavior, the patches in kbuild-next suggest the project is ready to "bite the bullet" and adopt the extensions system-wide. Phoronix reports: Rasmus Villemoes argued with Kbuild: enable -fms-extensions that would allow for "prettier code" and others have noted in the past the potential for saving stack space and all around being beneficial in being able to leverage the Microsoft C behavior: "Once in a while, it turns out that enabling -fms-extensions could allow some slightly prettier code. But every time it has come up, the code that had to be used instead has been deemed 'not too awful' and not worth introducing another compiler flag for. That's probably true for each individual case, but then it's somewhat of a chicken/egg situation. If we just 'bite the bullet' as Linus says and enable it once and for all, it is available whenever a use case turns up, and no individual case has to justify it..."
The second patch is kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS to ensure -fms-extensions is passed for the CPU architectures that rely on their own CFLAGS being set rather than the main KBUILD_CFLAGS. Linus Torvalds chimed in on the prior mailing list discussion and doesn't appear to be against enabling -fms-extensions beginning with the Linux 6.19 kernel.
The second patch is kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS to ensure -fms-extensions is passed for the CPU architectures that rely on their own CFLAGS being set rather than the main KBUILD_CFLAGS. Linus Torvalds chimed in on the prior mailing list discussion and doesn't appear to be against enabling -fms-extensions beginning with the Linux 6.19 kernel.
Re: (Score:1)
There are exactly three C compilers still being updated to the newest "standards" so they might as well just bite the bullet and make those extensions part of the actual C standard since all three already implement the features.
A number of the gnu and ms extensions have been proposed to be added to the next C standard. As with all such proposals, some might be added, some might need to be modified or replaced by equivalent language extensions, and some will not make the next C standard.
Well, I suppose -fms-extensions is better than (Score:5, Funny)
-embrace-extend-extinguish
Re:Well, I suppose -fms-extensions is better than (Score:5, Informative)
It's a GNU-flavored version of those MS extensions, originally they added a subset of what MS does in order to let gcc use data structures in MS's headers and have somewhat source compatible builds (I think this was roughly around the time Cygwin popped up, but I'm not sure).
A fair number of professional teams enabled those extensions for non-Windows code because they like some of the tricks available with the extensions and use it in their proprietary or open source code. It's a trend that has finally spread to the Linux kernel. I think this was really only possible as some of the kernel grognards retired or were otherwise not around to put up a fight and generally maintain the inertia force on LKML. Torvalds himself isn't quite as grumpy as people think and is generally pretty pragmatic and can be influenced by consensus and reasonable arguments.
Re: (Score:2)
Or maybe he has more clue about those "microsoft extensions" actually do.
Re: (Score:3)
Hopefully anyone with GNU info installed knows what it does.
There are two things it does, one of which helps parse those pesky Windows headers when using C++. Of course that doesn't apply at all to Linux as it is not Windows and doesn't use C++ in the kernel. The other is unnamed struct/union members, which is standard in modern C but the Linux kernel isn't quite willing to accept everything in C11, so picking up some extensions that are accepted is the compromise.
Re: (Score:2)
in order to let gcc use data structures in MS's headers and have somewhat source compatible builds
This is what I fear. I'm just not certain whose source will be "leaking" into whose kernel. Or why, if Linux devs (Linus) have decided up to this point _not_ to adopt a standard C construct, it is now considered to be a good idea.
Are we developing Linux using the Cut-N-Paste culture of Stack Overflow?
Re: Well, I suppose -fms-extensions is better than (Score:2)
You often need to do that to compile your open source software on Windows. It's got nothing to do with cut and paste or Microsoft stuff leaking into open source.
Old Terminology (Score:1)
Re: (Score:1, Insightful)
When is VisualBasic kernel support coming? (Score:1)
I really would like to see that to use some of those DLL extensions I still have laying around.
Re: (Score:2)
LoB
Kernel (Score:2)
Re: (Score:2)
"If you're root, you are assumed to know what you're doing"
Clearly you've never used MacOS where even root is a 2nd class user in some instances. All for security reasons don't you know - System Integrity Protection or whatever they've called it this month.
Re: (Score:2)
Regurgitating BOFH mantra might sound bad ass, but it has never been reality.
Re: (Score:2)
You need to specifically set those up in selinux, pam or apparmor. Out the box root can do anything in standard linux. Thats not the case in MacOS.
Re: (Score:2)
macOS root starts out with full userspace privileges, and they are reduced as the OS-at-large boots, exactly how a linux userspace works.
With namespaces, one can wall root off from the entire operating system.
Really, you're just talking out of your ass. Like I said, BOFH mantra might sound bad-ass, but it's wrong. Always has been.
Re: Kernel (Score:2)
Reduced as the os boots? Are you drunk? The kernel can do what it likes, userspace root cant. I would suggest you're talking out your arse but I doubt t you could find it with both hands.
Re: (Score:2)
When you apply an AppArmor profile as part of your init, you have effectively limited root's permissions.
Or, if your initrd actually mounts an overlayfs on top of a root to prevent you from writing to the filesystem as root- that is an effective limitation of root's permissions.
You're out of your depth here, dipshit.
Bad name, they're not actually microsoft (Score:5, Informative)
The actual feature enabled by the "-fms-extensions" option in gcc is anonymous member structs and unions, which had first appeared in plan9 and was invented by the same people who created the C language in the first place.
Re:Bad name, they're not actually microsoft (Score:5, Informative)
That extension basically lets you to extend C structs like in C++, but allows you to add new members *both* at the start and at the end of the base struct:
struct foo {
int m;
};
struct bar {
int before;
struct foo;
int after;
};
int main() {
struct bar b; b.m = 33;
}
Re: (Score:2)
IMO this is a good thing, not a bad one.
Re: (Score:3)
Or rather, unnamed unions:
struct my_struct {
int a;
union {
int b;
double c;
void* d;
};
int e;
} foo, *bar;
You can then reference t as foo,a, foo.b, foo.c, foo.d, and foo.e.
Without it the union must be named:
struct my_struct {
Re: (Score:2)
Example:
struct object {
enum object_type type;
union {
struct { struct object *car; struct object *cdr; };
double number;
};
};
struct object *foo;
Now we can say foo->cdr instead of (say) foo->value.cons.cdr.
Re: (Score:1)
Re: (Score:2)
Oops yes, in trying to give a realistic example I forgot to use the actual feature in question. The extension is that the internal struct or union may have a tag, and indeed may be declared elsewhere. So it could be "union {struct cons; double number;}".
C standard vs C 'common usage' (Score:2)
I would have thought there are advantages to keeping the Linux kernel as a 'strictly conforming application' using only the standard C language features.
Re:C standard vs C 'common usage' (Score:4, Insightful)
No operating system kernel - or even a non-trivial user program - is ever a strictly conforming C program; that term is so rigidly defined as to be almost useless (https://c-faq.com/ansi/compliance.html). But apart from that the Linux kernel already uses many gcc extensions, so adding another is not an issue.
Re: (Score:1)
Stick to standards (Score:3)
Blech.
While I can appreciate the motivation, it is always best to stick to widely recognized standards as far as programming languages go.
Re: (Score:2)
Can someone smarter than me.... (Score:2)
Explain the potential security implications, assuming there are any?
Re: (Score:2)
LoB
Yes ... No (Score:2)
As a step toward application portability between Microsoft apps and Linux systems, maybe. But that seems to be more at the library level. But who out there is suggesting that we need to splice Microsoft stuff (drivers, etc.) directly into the Linux kernel?
On the other hand, it could help in porting systemd to Windows.
Re: (Score:3, Insightful)
Application portability doesn't enter into it, nor does this have anything to do with code at a binary or library level. Nothing to do with Windows drivers! Not sure why you brought that up.
This is the Linux kernel we're talking about. This extension allows slightly cleaner, easier-to-read syntax in certain circumstances. As I understand it, it's syntactic sugar that brings a bit of C++'s ability to cleanly extend structs to C. This is clearly shown by some insightful comments above.
Nice dig at systemd,
Re: (Score:2)
This is about a language extension that adds great quality-of-life to struct declarations.
If you think a language barrier is what holds systemd back from $any_non_linux_os, then you are so fucking out of your depth here that I assume you must have drowned hours ago, and the noise is just now reaching us.