The embedded compiler vendors, UNIX and consoles are quite happy with it.
How much do you think they contribute back upstream regarding ISO compliance outside LLVM backend for their hardware and OS?
How much do you think they contribute back upstream regarding ISO compliance outside LLVM backend for their hardware and OS?
They contribute some things, sure. But the also don't contribute some things. It is hard to know how much because it's kept secret from all of us, even their own customers.
> "It's not like the Rust compiler is proprietary software with their own closed-source fork of LLVM..."
Rust no, hut there are a lot of proprietary, semi-incompatible proprietary forks out there.
One of the reasons that LLVM has been able to evolve so quickly is because of all the corporate contribution it gets.
GCC users want Clang/LLVM users to know how dumb they are for taking advantage of all the voluntary corporate investment in Clang/LLVM because, if you just used GCC instead, corporate contributions would be involuntary.
The GPL teaches us that we are not really free unless we have taken choice away from the developers and contributors who provide the code we use. This is the “fifth freedom”.
The “four freedoms” that the Free Software Foundation talks about are all provided by MIT and BSD. Those only represent “partial freedom”.
Only the GPL makes you “fully free” by providing the “fifth freedom”—-freedom to claim ownership over code other people will write in the future.
Sure, the “other people” are less free. But that is the price that needs to be paid for our freedom. Proper freedom (“full freedom”) is always rooted in the subjugation of others.
But hey, if you try hard to be nice to your master and do not demand anything, for sure they will always treat you well!
I think that's the core difference.
I have not tried OpenIndiana, however.
Gnu promotes Unix, but also promotes Emacs on top. NT can run Win32 on top of it, but there's far more than Win32 with NT systems. Just get ReactOS and open the NT object explorer under explorer.exe.
Far more advanced than Windows 95/98.
It almost sounds like you think UNIX is an API like Win32, and that GNU is an operating system which "implements UNIX" like NT is an operating system which "implements Win32"? Are you confusing UNIX with POSIX?
GNU was made to replace UNIX, not to promote it.
Even OpenBSD is not as 'pure Unix' as Unix V7.
I am still waiting for the counter examples regarding clang contributions.
The one vendor who forks LLVM and doesn't contribute their biggest patches back is Apple, and if you want bleeding edge or compliance you're not using Apple Clang at all.
If you say "isn't it great vendor toolchains have to contribute back to upstream?" I'm going to say "no, it sucks that vendor toolchains have to exist"
If a company makes a new MCU with some exciting new instruction set, they need to make a compiler available which supports that instruction set and make that compiler available to their customers.
With LLVM as the base, the vendor could make their toolchain proprietary, making it impossible to integrate it back into LLVM, which means the vendor toolchain will exist until the ISA gets wide-spread enough for volunteers to invest the time required to make a separate production-quality LLVM back-end from scratch.
With GCC as the base, the vendor must at least make their GCC fork available to their customers under the GPL. This, in theory, allows the GCC community to "just" integrate the back-end developed by the vendor into GCC rather than starting from scratch.
Now I don't know how effective this is, or how much it happens in practice that the GCC project integrates back-ends from vendor toolchains. But in principle, it's great that vendors have to make their toolchains FOSS because it reduces the need for vendor toolchains.
Code getting open source is not impossible. Companies do it all of the time because it's expensive to rebase.
Previous reality: companies write fully proprietary code to avoid GCC
Current reality: companies choose Clang over GCC because of the license and then contribute many of their changes back.
Because Apple certainly isn't alone.
Clang has a very nice specific page for ISO C version compliance: https://clang.llvm.org/c_status.html#c2x
I could not find the same for GCC, but I found an old one for C99: https://gcc.gnu.org/c99status.html
CppRef has a joint page, but honestly, I am more likely to believe a page directly owned/controlled/authored by the project itself: https://en.cppreference.com/w/c/compiler_support/23
Finally, is there a specific feature of C23 that you need that Clang does not support?
GCC's support for C23 is essentially complete. Clang is mostly catching up, but features I need that I am missing are storage class in compound literals and tag compatibility. It is also sad that Clang does not implement strict aliasing correctly (it applies C++'s rules also in C).