"Undefined Behavior", a.k.a. "don't do that". It's everything the language allows you to do but the spec (you didn't read) says you should not, otherwise anything can happen. For example you should not access an array out of bounds, nor dereference a null pointer; so the compiler is free to assume this will never happen, and if it does the generated code may do very unexpected things, like not a straight segfault but continue running with unintended behavior.
There are many UB cases in C/C++ many programmers don't suspect (more subtle than dereferencing null), and this regularly introduces very hard-to-debug bugs and securities issues. Rust does (mostly) get rid of them so you can be sure that your code has no unexpected side-effects.
This, to me, reads like it implies that reading the spec shouldn't be necessary to use a language correctly. The issue with that is that the spec is the only document you need to read, understand and follow in order to write safe, cross-implementation-compatible code.
When you work with low-level languages and refuse to read the spec carefully, you are to blame more than the language or the spec.
this regularly introduces very hard-to-debug bugs and securities issues
Yeah, that's true. The reality is that a lot of developers come from a C-syntax language (like C#, C, Java, ...) and assume that it's all the same because it looks the same. Mostly they follow video tutorials on youtube and blog-y websites instead of standard-adhering documentation (like cppreference.com). I've seen C++ developers that, after building 10k+ line of code programs, never knew why to use `delete`, what RAII even is, and have not a clue about what a mutex does.
These are fundamental education problems. Rust has the benefit of being different enough from common "first languages" that one is inclined to look at the documentation.
I'm not the only one who is endlessly tired of being told that the design of C++, with its undefined behavior and "need to read the spec", is somehow at fault for developers being too stubborn, entitled or stupid to take 3 minutes to read and understand the documentation.
When a Rust developer makes a security mistake, causes a crash or other unexpected behavior, the developer is likely at fault. With C++, it's always "oh c++ is just like that". It's a complete mystery to me how people cannot understand that sometimes a language with lots of power can have pitfalls that need to be avoided by the programmer.
The difference is that the C++ spec is ~1700+ pages of very dense and oftentimes subtle language that no one fully understands. Moreover, even the committee can't tell you all the UB that exists. There's a proposal to simply enumerate the explicit UB [1] they do know about, but even that doesn't exist yet.
When the situation with the language is such that no human or program yet invented can confidently assert the defined-ness of any particular bit of code, it's 100% the language's fault. Who else could be at fault for it being impossible to write safely?
An amusing anecdote is that there's a conference for UB detectors called sv-comp. They have a suite of example programs with completely defined behavior that are used to detect false-positives. People keep finding UB in the C examples [2].
developers being too stubborn, entitled or stupid to take 3 minutes to read and understand the documentation.
Understanding C++ from first principles to the level that you never write UB, by reading the spec, is much closer to a 3 decades task than a 3 minute task.
The audience for such a spec is mostly compiler authors and similar categories. A lot of people using a language don't need to internalize chapter and verse.
When you work with low-level languages and refuse to read the spec carefully, you are to blame more than the language or the spec.
This is true to some extent but I think there is a reasonable argument that the language specs are generally geared towards people building compilers or similar tools, and it's not reasonable to expect everyone who works with a language to be intimately familiar with the spec at that level. In the case of C++, the language complexity seems to be at the point where even people who are highly-skilled and work on tools like Clang are still hesitant to say they fully understand the rules around undefined behaviour.
Comments
"Undefined Behavior", a.k.a. "don't do that". It's everything the language allows you to do but the spec (you didn't read) says you should not, otherwise anything can happen. For example you should not access an array out of bounds, nor dereference a null pointer; so the compiler is free to assume this will never happen, and if it does the generated code may do very unexpected things, like not a straight segfault but continue running with unintended behavior.
There are many UB cases in C/C++ many programmers don't suspect (more subtle than dereferencing null), and this regularly introduces very hard-to-debug bugs and securities issues. Rust does (mostly) get rid of them so you can be sure that your code has no unexpected side-effects.
This, to me, reads like it implies that reading the spec shouldn't be necessary to use a language correctly. The issue with that is that the spec is the only document you need to read, understand and follow in order to write safe, cross-implementation-compatible code.
When you work with low-level languages and refuse to read the spec carefully, you are to blame more than the language or the spec.
Yeah, that's true. The reality is that a lot of developers come from a C-syntax language (like C#, C, Java, ...) and assume that it's all the same because it looks the same. Mostly they follow video tutorials on youtube and blog-y websites instead of standard-adhering documentation (like cppreference.com). I've seen C++ developers that, after building 10k+ line of code programs, never knew why to use `delete`, what RAII even is, and have not a clue about what a mutex does.
These are fundamental education problems. Rust has the benefit of being different enough from common "first languages" that one is inclined to look at the documentation.
I'm not the only one who is endlessly tired of being told that the design of C++, with its undefined behavior and "need to read the spec", is somehow at fault for developers being too stubborn, entitled or stupid to take 3 minutes to read and understand the documentation.
When a Rust developer makes a security mistake, causes a crash or other unexpected behavior, the developer is likely at fault. With C++, it's always "oh c++ is just like that". It's a complete mystery to me how people cannot understand that sometimes a language with lots of power can have pitfalls that need to be avoided by the programmer.
The difference is that the C++ spec is ~1700+ pages of very dense and oftentimes subtle language that no one fully understands. Moreover, even the committee can't tell you all the UB that exists. There's a proposal to simply enumerate the explicit UB [1] they do know about, but even that doesn't exist yet.
When the situation with the language is such that no human or program yet invented can confidently assert the defined-ness of any particular bit of code, it's 100% the language's fault. Who else could be at fault for it being impossible to write safely?
An amusing anecdote is that there's a conference for UB detectors called sv-comp. They have a suite of example programs with completely defined behavior that are used to detect false-positives. People keep finding UB in the C examples [2].
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p170...
[2] https://runtimeverification.com/blog/mare-than-14-of-sv-comp...
Understanding C++ from first principles to the level that you never write UB, by reading the spec, is much closer to a 3 decades task than a 3 minute task.
The audience for such a spec is mostly compiler authors and similar categories. A lot of people using a language don't need to internalize chapter and verse.
This is true to some extent but I think there is a reasonable argument that the language specs are generally geared towards people building compilers or similar tools, and it's not reasonable to expect everyone who works with a language to be intimately familiar with the spec at that level. In the case of C++, the language complexity seems to be at the point where even people who are highly-skilled and work on tools like Clang are still hesitant to say they fully understand the rules around undefined behaviour.