51–60 of 73 posts
Earlier quoted context omitted.
[flagged]
It is entirely unclear to me what point you are trying to make. Is your mundane solution to just add more sanitization and analysis to C and C++? If so, that's great, more safety in any language is fantastic. My issue with that is that it is an optional addition to the language rather than the default behavior. The point I am making is that safe Rust _by default_ straight up disallows compiling code that has the pote…
Earlier quoted context omitted.
> Your blend of comments makes it sound like no one knew or cared about these issues other than Rust fanboys. That is a strange takeaway from my post. Of course people care, but the difference is that one language and its toolchain was designed and built specifically to avoid these bugs and one wasn't. I have been writing C++ professionally since around 2000-2001, and have been working with Rust for about 18 months.…
[flagged]
> You are claiming that static code analysis tools extensively used in C++ cannot detect all conceivable and hypothetical memory issues. The weasel words in here is that it is possible to detect them, but some can conceivably slip through.
No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem.
> To drive the point home, there are already a few CVEs even from use-after-free bugs in Rust code. What does that make out of the all assertion? Would this be a reasonable argument to reject Rust as an unsafe language?
The CVE that you referenced in the other comment was Rust calling into unsafe C code, as I pointed out. If you have a real example feel free to post it.
> The problem with these claims is that they rely on weak strawmen arguments and a very superficial analysis of the problem space. I get the need to do marketing, but if the audience is technical them don't you think arguments should stand on solid technical ground?
The views I have laid out here are the consensus among compiler engineers and in theoretical computer science. You only have to look at the compiler group at Apple:
- heavily invested in static analysis - maintains the clang static analyzer - maintains number of runtime memory analysis tools in Xcode - not invested in rust at all and seemingly not interested
Yet they are adding lifetime dependency annotations to Swift, making it more like Rust: https://github.com/swiftlang/swift-evolution/blob/ef71df4158...
The reason for this is that static analysis simply cannot do it when the semantic information about lifetimes is lost, even for a group that knows how to write strong static analysis tools. Program flow is too ambiguous without it, so it becomes impossible to detect such memory vulnerabilities without running the program and fuzzing it – an expensive, time consuming, and probabilistic process.
[flagged]
Earlier quoted context omitted.
> Even the most novice Rust programmer who stays in the guardrails I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. I’ve no experience with either language and I can safely say I’d have no idea which switches to “just flip” in the compiler and what tools I should look up to write safe C++ code. I do know that “Learn Language X” books do not include this…
> I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no o…
Earlier quoted context omitted.
> I think this part answers your question. A novice could produce reasonably safe Rust code by just reading a book. That blend of comments is at best grasping at straws. How long do you think a developer stays a "novice"? Does Rust have any problem that prevents developers from learning and improving their skills as fast as any other developers do? Are all Rust projects maintained by novice and junior devs where no o…
So why all the software is still so insecure?
The rust driver does read better. I like that the functions are organized as methods under a member less struct, as opposed to the C version where they are top level with_really_long_function_names that take a struct parameter.
Earlier quoted context omitted.
> Presumably because decades of experience has shown that it doesn't. What definition of "doesn't" do you adhere to? Because there are use-after-free CVEs from Rust code. https://nvd.nist.gov/vuln/detail/CVE-2025-48752
This is not a very good example, because this Rust code is a thin wrapper around pthread_mutex, which is an unsafe API that can cause undefined behavior (such as use after free) if used incorrectly. The Rust code in question is using the unsafe C API incorrectly. https://github.com/Forestryks/process-sync-rs/issues/3 One could say "Rust doesn't stop you from calling out into unsafe C code, so it's still possible to p…
Feel free to pick an example that tickles your fancy.
[flagged]
Majority of cpp knowledge is not universal computer science, but cpp's quirks, issues, tricks, hacks and wasted life fighting lack of coherent building system and package manager alongside of long compile times
This is a very important point if the tool is used by millions of people. All you need to do is waste a few 10s of seconds with some weird quirk that doesn’t act as expected, and BAM, collectively easily a year of human life was wasted.
Avoid surprising behavior.
Earlier quoted context omitted.
[flagged]
Replying to your other comment. > You are claiming that static code analysis tools extensively used in C++ cannot detect all conceivable and hypothetical memory issues. The weasel words in here is that it is possible to detect them, but some can conceivably slip through. No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the…
This is the sort of goalpost-moving that lays bare how superficial and misleading these accusations are. You're trying to argue that some very specific types of memory vulnerabilities can't be detected with static code analysis tools. That is different than claiming that it's not possible to detect memory vulnerabilities in languages such as C or C++, isn't it? But somehow this strawman is used to imply that Rust is invulnerable whereas developers using any other language are prevented from ever learning that standard FLOSS compilers support out of the box things such as detecting use of uninitialized variables.
So what is it then?
Earlier quoted context omitted.
In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside t…
> In safe rust you cannot read uninitialized memory or variables, you cannot dereference a null or freed pointer, you can't concurrently mutate the same variable from multiple threads without locking primitives, you can't accidentally modify a variable after it has been moved out of scope - all of these things are enforced at compile time. If your code compiles, you are safe from all of these classes of bugs (outside…
(What's more, Rust is substantially nicer to use than C++. The language, package manager, and compiler are all so much more straightforward than C++ that I would use it for that alone)