141–150 of 157 posts
Earlier quoted context omitted.
Data races are a source of bugs. They are not a noticeable fraction of the security issues that face memory unsafe languages, which is the practical argument for memory safety.
No they’re pretty important these days now that basic linear overflows and the like are harder to exploit
This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
is go not memory safe? other than unsafe and other contrived goroutine scenarios, isn't it? I'm actually really curious - I've been writing go for just a couple years now and my understanding is the only ways for it to be unsafe are the two scenarios I described earlier.
Earlier quoted context omitted.
Rust has double free concurrency bugs https://materialize.com/blog/rust-concurrency-bug-unbounded-... Lockbud: project detailing memory, concurrency bugs and panics for Rust. https://github.com/BurtonQin/lockbud USENIX paper on model checking for Rust OS kernels uncovered 20 concurrency bugs across 12 modules in projects like Redox OS and Tock, including data races, deadlocks, and livelocks https://www.usenix.org/sys…
You've linked to a bug that was unintentional and was fixed. Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed. Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.
Earlier quoted context omitted.
I see, you wish to limit the domain. Do safety issues in the async runtime count ? Or is even "async Rust" out of your criteria ? What about this one ? "Futurelock in Tokyo" ? https://rfd.shared.oxide.computer/rfd/0609
> What about this one ? "Futurelock in Tokyo" ? Deadlocks are not memory safety issues by the definition used in the OP. Furthermore, safe Rust is only intended to guarantee protection against data races, not race conditions in general.
'static closures/FnDefs/futures with non-'static return type are unsound https://github.com/rust-lang/rust/issues/84366
Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) https://github.com/rust-lang/rust/issues/63818
Earlier quoted context omitted.
> The complaint is that they've got a new hammer and then start seeing nails everywhere. Ah, my apologies for misreading the original comment I replied to then. > This was mostly because they didn't solve the performance problem. In the domains where that matters less, other languages did make significant inroads. Java, Python, etc. have significant usage in domains that before them were often C or C++. Which is true…
C# AOT is performant, is easy to use and has a small footprint. (Less than a megabyte executable without trickery. I am sure one could get much smaller if someone put effort into it.)
That being said, I wouldn't be surprised if it (and similar capabilities from Graal, etc.) grabbed yet more market share due to making those languages more viable where they historically had not been.
Earlier quoted context omitted.
> What about this one ? "Futurelock in Tokyo" ? Deadlocks are not memory safety issues by the definition used in the OP. Furthermore, safe Rust is only intended to guarantee protection against data races, not race conditions in general.
What about these ones ? They are considered memory-safety/soundness issues 'static closures/FnDefs/futures with non-'static return type are unsound https://github.com/rust-lang/rust/issues/84366 Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) https://github.com/rust-lang/rust/issues/63818
But anyways, at least from a quick glance those would at the very least seem to run into codys' unintentional bug vs. intentional behavior distinction. The bugs you linked are... well... bugs that the Rust devs fully intend to fix regardless of whether any in-the-wild exploits ever arise. The Go data race issue, on the other hand, is an intentional implementation decision and the devs have not indicated any interest in fixing it so far.
Earlier quoted context omitted.
What about these ones ? They are considered memory-safety/soundness issues 'static closures/FnDefs/futures with non-'static return type are unsound https://github.com/rust-lang/rust/issues/84366 Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) https://github.com/rust-lang/rust/issues/63818
I think this is starting to wander rather far afield from where this thread started... But anyways, at least from a quick glance those would at the very least seem to run into codys' unintentional bug vs. intentional behavior distinction. The bugs you linked are... well... bugs that the Rust devs fully intend to fix regardless of whether any in-the-wild exploits ever arise. The Go data race issue, on the other hand,…
Earlier quoted context omitted.
I dislike Java's abstraction-through-indirection approach, which is related to the non-representable invalid states you mention. But I think it's more of a matter of taste. Somewhat controversially, I think Java is actually doing fine on null safety: it uses the same approach for it as it does for array index safety. The latter is a problem for any language with arrays without dependent types: out-of-bounds accesses…
I'm not talking about null safety in the sense of null pointers. Null pointers and out of bound pointers are still in the realm of memory safety, which of course Java has solved for the most part. Proper null safety (sometimes called void safety) is to actually systematically eliminate null values, to force in the type system a path of either handling or explicitly crashing. This is what many newer expressive multi-p…
Earlier quoted context omitted.
I dislike Java's abstraction-through-indirection approach, which is related to the non-representable invalid states you mention. But I think it's more of a matter of taste. Somewhat controversially, I think Java is actually doing fine on null safety: it uses the same approach for it as it does for array index safety. The latter is a problem for any language with arrays without dependent types: out-of-bounds accesses…
I'm not talking about null safety in the sense of null pointers. Null pointers and out of bound pointers are still in the realm of memory safety, which of course Java has solved for the most part. Proper null safety (sometimes called void safety) is to actually systematically eliminate null values, to force in the type system a path of either handling or explicitly crashing. This is what many newer expressive multi-p…
I find it strange that this web site completely ignores the Java ecosystem, which offers memory-safe implementations for most of the protocols and services listed.
> Memory safe languages include Rust, Go, C#, Java, Swift, Python, and JavaScript. Languages that are not memory safe include C, C++, and assembly.