Two patches queued into the Linux kernel’s build system development tree, kbuild-next, would enable the -fms-extensions compiler argument everywhere for allowing GCC and LLVM/Clang to use the Microsoft C Extensions when compiling the Linux kernel. Being in kbuild-next these patches will likely be submitted for the Linux 6.19 kernel merge window next month but remains to be seen if there will be any last minute objections to this change.

The -fms-extensions compiler option honored by the GNU Compiler Collection and LLVM/Clang allow enabling some non-standard C/C++ constructs used within Microsoft header files and honored by the the Microsoft Visual C/C++ compiler. For Linux kernel development purposes, enabling the Microsoft C Extensions would allow including a tagged struct or union anonymously in another struct/union.

  • Truscape@lemmy.blahaj.zone
    15·
    4 hours ago

    Would this cause consequences in terms of the project’s independence? Or are these extensions able to be distributed freely?

    • GreenCrunch@piefed.blahaj.zoneEnglish
      48·
      4 hours ago

      From what I can see, the GNU Compiler Collection supports this flag, so you can still build it with 100% free software.

      Basically, it’s just behavior that doesn’t align with the C standard, but was introduced by MS. Then, GCC added a compiler flag which makes it behave like that, so that you can build code that requires that behavior.

      It doesn’t seem to actually be dependent on MS, rather it’s named after them because it emulates the way their compiler works. I hope no Linux maintainers would entertain the idea of making it dependent on a non-free compiler.

      • clif@lemmy.world
        5·
        1 hour ago

        behavior that doesn’t align with the C standard … but was introduced by MS

        Yep, that tracks. I’m still pissed off about microsoft’s non-standard implementation of HTTP 1.1 from however long ago it was that I had to conditionally work around it on the server side. They believe standards don’t apply to them and it seems like they’re right.

    • entwine@programming.dev
      25·
      2 hours ago

      I’m sitting around doing IT shit waiting things to download/backup/install/etc and have nothing better to do, so here’s an AI-free explanation with code samples:

      It’s basically just a code style thing. Standard C allows you to declare unnamed structs/unions within other structs/unions. They must be unnamed, so it’d look like this:

      struct test {
        int a;
        struct {
                char b;
                float c;
        };
        double d;
};

      Which is fine, but the -fms-extensions flag enables you to do the same thing with named structs. For example:

      struct test {
        int a;
        struct test2 {
                char b;
                float c;
        };
        double d;
};

      without -fms-extensions, the above will compile, but won’t do what you might assume. b and c will be members of struct test2, not test. So something like this won’t compile:

      struct test my_test;
my_test.b = 1; // error: ‘struct test’ has no member named ‘b’

      But with the flag, not only does it work, it also lets you do some convenient things like this:

      struct test2 {
        char b;
        float c;
};
struct test {
        int a;
        struct test2;
        double d;
};
//...
struct test my_test;
my_test.b = 1; //OK

      That is, you can reuse an existing struct definition, which gives you a nice little tool to organize your code.

      Source: https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html