3 ms·
"offer memory safety at compile time through the use of static analysis" For arrays, this problem is not computable at compile time, hence the sarcastic remark
by bgwalter 1y ago
"offer memory safety at compile time through the use of static analysis"
For arrays, this problem is not computable at compile time, hence the sarcastic remark that, IF THE ABOVE DEFINITION IS TAKEN AT FACE VALUE, Rust must have solved the halting problem. Downvoters are so dumb here.
- deleted 1y ago[deleted]
- Jtsummers 1y ago> IF THE ABOVE DEFINITION IS TAKEN AT FACE VALUE Why are you shouting? That's what twits do. You don't want to be a twit, do you? Read the site guidelines, emphasis is done with italicized text marked up with an * at the beginning and another * at the end. But to respond to the topic at hand: Are you familiar with the distinction between sound (what Rust aims for) and complete analyses?
- bgwalter 1y agoAre you familiar with the fact that Rust does array bounds checking at runtime, contrary to the cited claim? And that this was kind of the topic of this subthread? https://stackoverflow.com/questions/28389371/why-does-rust-check-array-bounds-at-runtime-when-most-other-checks-occur-at-c https://stackoverflow.com/questions/28389371/why-does-rust-c...
- deleted 1y ago[deleted]
- deleted 1y ago[deleted]
- vlovich123 1y agoAre you aware you’ve built a straw man and replied to it? Literally you quoted: > Rust's big step function was to offer memory safety at compile time through the use of static analysis borrowed and grown out of prior efforts such as Cyclone, a research programming language formulated as a safe subset of C. It is absolutely true that memory safety is offered at compile time in Rust which is a novel thing. You then pivoted this to start talking about bounds safety of arrays which is a strawman interpretation of what was written.
- bgwalter 1y agoBounds checking is part of "memory safety" and Rust people don't get the monopoly on that term. The definition of "memory safety" is literally the topic of this subthread.
- bgwalter 1y agoI did not pivot. TFA itself defines: "Memory safety—the property that makes software devoid of weaknesses such as buffer overflows, double-frees, and similar issues—has been a popular topic in software communities over the past decade" And the buffer overflows are not detected statically except for the cases when the compiler can prove them. And Rust proponents keep ignoring the topic of this subthread, which is memory safety by static analysis.
- vlovich123 1y agoAs others have pointed out to you. Memory safety is enforced at compile time through static analysis. This does not mean the absence of runtime checks - that is a property you are injecting into the definition and arguing about. RefCell enforces memory safety too by doing the lifetime enforcement at runtime by using UnsafeCell to provide certain semantics. But the compiler ensures that the RefCell itself still has correct lifetimes and is used correctly, resulting in a compile time guarantee that the code that’s run is memory safe.
- bgwalter 1y agoSince it seems that Rust programmers are unable to provide a definition for "memory safety", here is what more mature and academically minded people think: https://blog.adacore.com/memory-safety-in-rust https://blog.adacore.com/memory-safety-in-rust Notice that in-bounds indexing is included, same as in the definition from this submission that I quoted at you.
- vlovich123 1y agoAgain, no one is arguing that bounds checking isn’t required for memory safety. You are intentionally continuing to argue against a position no one has taken anywhere that Rust somehow always has 0 runtime safety checking and everything happens statically at compile time. Literally RefCell and array bounds. I keep trying to clarify the wording that’s in the article and what it’s intended to mean that you have issue with and instead you keep insisting it means the wrong thing literally no one has argued for.