But even if you do use GCC or Clang, it doesn't change the mechanics of C++ as a poor language for embedded or operating system work. It just means you have the same choices (e.g. limited support for containers and strings, no exceptions, limited smart pointers, etc.) and you're making that choice based on GCC or Clang's limits.
And on a validated RTOS - it might be in C++ under the covers. The examples that come to my mind aren't. But the world is a big and magical place, so I can't say for certain on every RTOS. The F35 uses C++ and a set of very restrictive internal coding standards built on https://en.wikipedia.org/wiki/MISRA_C.
And no one will die if their copy of Serenity OS crashes.
Regarding language guides, C doesn't stop being C, even when castrated via MISRA-C.
What does a vendor compiler do or do better than a compatible generic one?
With a vendor supplied compiler you can say, "We're using version 11.2". A year or two later an issue is discovered, the vendor will backport a fix to 11.2 giving you 11.2.1 which is much less effort for recertification. You aren't depending on the kindness of strangers (a terrible strategy) because you're actually paying someone to do the work.
Do the vendor compilers have a very focused feature set as a result? To reduce both test surface area and chance of expensive mistakes?
Most OS code is written in C++ or Object-C, not C. Between Android, MacOS/iOS, and Windows there's not a lot of C code. The kernels are most of it. The NT kernel has C++, but hard to get a source on how much is still C or not. But the kernel is far from being most of the OS regardless.
> The fact that C doesn't require a runtime (nor does Ada), means you can use it to write kernels. You can't do the same with a 'full' version of C++, so you're back to a cut down C++.
For a huge number of users, "full" C++ is C++ with -fno-exceptions and -fno-rtti anyway, at which point the 'runtime' is like 2 functions and it's absolutely perfectly fine to use in a kernel. But regardless neither of those features are inherently incompatible with being in a kernel. You just have to implement a runtime to do that, just like kernels written in C have to implement a libc replacement.
Unless you're talking about the standard library (even though nearly all of it is completely kernel-compatible out of the box), but then you'd have to include libc & friends in the "C runtime" category and then it's equally impossible to use in a kernel.
And C in the kernel isn’t really a libc replacement. They often have different behaviors because they need to run without allocating memory, or be interrupt safe. For example, in some situations I use a function call instruction that specifically does not creat a new stack frame.
And of course asm {} works the same regardless.
I work on embedded systems. There are roughly 3 choices for languages[1]. C, Ada, and C++. Except the version of C++ is sometimes often vendor specific and may lack features that are "standard C++", and never have a "full" STL. In addition, if you're not super careful with C++, what you thought was a copy or declaration can execute additional constructor or assignment logic. It might just interfere with your estimate of how long something can take (which is super important in interrupt handlers), or worst case, smash your stack (which can be as small as 1-2k). With C, you pretty much know what's going to happen and what's getting called. The fact that C doesn't require a runtime (nor does Ada), means you can use it to write kernels. You can't do the same with a 'full' version of C++, so you're back to a cut down C++.
I also spend time debugging compiled, optimized code by tracing instructions. This is hard enough in C, where I don't magically jump to a constructor function or an assignment function. I can visualize in my head how the C code could look like, given the instructions the optimizer produced. So it may not look like my code, but it is a version of the code that I can at least logically infer.
Ada is nice, but outside of some super-safety critical realms, it hasn't had the uptake. Private industry prefers not having to make the investment and the government let everyone waive out of it.
1. I know people are going to to say 'what about Rust, Go, or embedded something or other?' They are not as mature in their development lifecycle. So there's no validated RTOS for Rust (there are some experimental ones). Go is even further behind. Basically, you need a vendor supported RTOS that's validated for the safety and operational requirements of your use case, before you can be a serious choice for a lot of embedded work.