What has the standard actually gotten C and C++? Basic features needed in every single code base like type punning on structures are standardly UB, while design-by-committee results in C++ feature hell.
It doesn't get any harder to write a function exhibiting a bug just because there's a standard saying the function shouldn't have bugs in it. No matter what, you are trusting a compiler vendor that the code it compiles and the functions it links against don't have bugs.
A standard is not a magic spell that creates better software through its incantation; it provides for multiple separate compiler vendors to be able to compile the same code the same way, which is a total fiction in C/C++, and not required for languages like Python or Lua. I view it as nothing more than the streetlight effect.
Prior to the C/C++ standardization process, every compiler implemented a different dialect of those languages, and there wasn’t a complete and accurate specification for them. Some very basic C code working with one compiler might not work on another.
I don’t think Rust or any other modern language needs to be standards-org standardized, but this is a different era; there is a single solid, well-documented, versioned reference implementation for Rust. That was never the case for C or C++.
Yeah I mean this is still kind of the case today, Rust just avoids it because there is really only one reference implementation. That may not even be true forever, Rust on GCC is continuing to get more and more feature complete over time. [1][2]
Take the "defer" keyword in GNU C - it's valid in anything that has the GNU extensions but isn't standard C at all. And yet, some projects swear by it (it's not a bad feature, just nonstandard).
There's a lot of weirdness in C implementations even looking across LLVM, GNU, or even when picking which libc you want! Try porting any nontrivial project to work with musl-libc. You might find that it's not as easy as swapping in a target and building statically!
This is perhaps the whole rub with standardization - it's bought us as developers a lot, but it doesn't cover everything. The veil was kind of lifted for me when I started trying to use different Scheme implementations in a "standardized" way. I eventually gave up on that and just use whatever implementation I am most happy with (often CHICKEN, but that's a digression).
This gets more complicated with C++, which modern standards mostly requires C11, but then also doesn't support everything that C11 requires either. They're different languages but yeah, compilers are gonna disagree on some of the edges there.
[2] tangentially, Rust also avoids some UB discussion because the type system is a bit more complete in terms of its properties than C is, so they can resort to Option or Result when things get dicey in an API. Further, there's no official Rust ABI unlike C, so you don't have to worry about that either...
> Some very basic C code working with one compiler might not work on another.
I teach C and C++, and you have no idea how often I hear "But it worked on my machine!" when I give back bad grades due to code that segfaults when I go to run it.
• FILE* was a big I/O abstraction that C did not have before. With Unixes and MS-DOS there were file handles, but many other platforms had nothing like that.
• That there was a clear idea of what kind of operations were well-defined was a pretty big deal. Remember, all there was before was K&R to go off as a reference, or maybe you had access to the Portable C Compiler. It was also a time where you had a lot more oddball architectures.
• void return types and parameters. There was no idea of a procedure in early C, only functions with useless return values.
And of course more. There are definitely worse cases of ISO standards than C and C++. Both are noticably better out of it.
> No matter what, you are trusting a compiler vendor that the code it compiles and the functions it links against don't have bugs.
I guess the key factor about a standard is that as a corporation you can point fingers if something goes wrong ("the compiler and/or the MISRA C checking tools you sold me are not compliant with the standard because of this bug!").
Also the committee can point fingers back if required ("the UB is clearly specified in the standard!").
If I were a team manager at a big automotive factory in charge of the ECU system, I would go the private way, with guarantees, and paying a lot of money. In case of failures, I can point fingers and someone would answer the phone on the other side if I complain.
Who should I call or who should I point my finger at, if something goes wrong because of a bug in Rust? A Github user on the other side of the planet?
If there were a standard, you'd still be pointing at opposite-hemisphere github users. This is what I mean about the streetlight effect - the standard has jack to do with the outcome. If you are buying a product from a vendor, the vendor is responsible for the product, and if you are using an open-source community-managed product, it's much harder to point fingers. The source of truth can be an ISO standard, or it can be documentation, it doesn't matter.
A part of the safety story of any useful toolchain compliant to ISO 26262 as a SEOOC is that it verifiably implements the language as documented in the standard. The "verifiably" part is important. If there is no standard to verify against, how do you know it's doing the right thing?
The language standards themselves state outright that programs containing undefined behaviour are malformed. If you write malformed programs, you can not assume that they are safe. Don't blame language standardization for your writing bad, unsafe software if you're not going to follow it.
In addition verifiably conformant compilers for translating your programs into software, the standard allows other tools to be written to perform things like static analysis, complexity analysis, and conformance to other published guidelines (eg. MISRA). These things are not possible where the definition of the language is "whatever one single toolchain vendor decides it will be this week".
It doesn't get any harder to write a function exhibiting a bug just because there's a standard saying the function shouldn't have bugs in it. No matter what, you are trusting a compiler vendor that the code it compiles and the functions it links against don't have bugs.
A standard is not a magic spell that creates better software through its incantation; it provides for multiple separate compiler vendors to be able to compile the same code the same way, which is a total fiction in C/C++, and not required for languages like Python or Lua. I view it as nothing more than the streetlight effect.