| I just wrote that as an observation, and I did not mean to offend the parent. Now, let me explain why I felt that way. First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it. The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation. For example, C/C++ specifications state that using a pointer after calling "free()" on it is UB. But an implementation can make it well-defined by adding a GC and making "free()" a no-op. Hence, memory safety is entirely orthogonal to UB. Another example: signed overflow being UB is not a memory safety problem unless the value is used for array indexing. Also, it is possible to enable bounds checking in STL containers (like _GLIBCXX_ASSERTIONS). It seems like that a lot of Rust fans read John Regehr's posts and use "undefined behavior" as a boogeyman to throw shade at C/C++. They repeat the same points ad nauseam. It also helps that the phrase "undefined behavior" evokes strong emotions (eg., "nasal demons"). I see the parent commenter doing this frequently and sometimes[1] even in the C++ subreddit (of all the places!). How is this not obnoxious? Here[2] is another person doing the same, but in a spicier tone. Linked lists and graphs are safe if you have an isoheap allocator (look at Fil-C). You can say that it is moral to endlessly reiterate the problems of unsafe languages, because it could lead to more secure software. But see the reply to my other comment by "hyperbrainer"[3] which says that Rust is "completely" memory safe, which is entirely wrong[4]. It is hard not to suspect the motives of those who claim to be concerned about memory safety. [1] -https://old.reddit.com/r/cpp/comments/1fu0y6n/when_a_backgro...
[2] - https://news.ycombinator.com/item?id=32121622
[3] - I am unable to reply because of the depth.
[4] - Rust requires unsafe to do a lot of things which can be done in safe code in a GC'd language. Thus, unsafe is pretty common in Rust than most GC'd languages. If a segfault can literally kill a person, it is absolutely immoral to choose Rust over Java (it does not matter that Rust "feels" safer than Java). |
Your point [4] is very silly because you're assuming that while the unsafe code implementing a safe Rust interface might be flawed the code implementing a safe Java interface such as its garbage collector (which will often be C++) cannot be. As we'd expect, both these components are occasionally defective, having been made by error prone humans, such flaws are neither impossible nor common in either system. There are indeed even safer choices, and I've recommended them - but they're not Garbage Collected.
> First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it.
Nope, those words have an ordinary meaning and are indeed used by Rust's own documentation, for example the Rustonomicon says at one point early on, "No matter what, Safe Rust can't cause Undefined Behavior". The purpose there is definitional, it's not a boast about how awesome Rust is, it's a claim that if there is Undefined Behaviour that's not because of the safe Rust, there's a soundness problem somewhere else.
> Another example: signed overflow being UB is not a memory safety problem unless the value is used for array indexing
This is wrong. Because Signed Overflow is UB the C++ compiler is allowed to just assume it will never happen, regardless of the systemic consequences. What that means is that other IR transformations will always be legal even if they wouldn't have been legal for any possible result of the overflow. This can and does destroy memory safety. Actually it would be weird if somehow the IR transformations always preserved memory safety, something they know nothing about, despite changing what the code does.