6 ms·

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 b

by codys 9mo ago

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.

lenkite 9mo ago
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 https://rfd.shared.oxide.computer/rfd/0609
- aw1621107 9mo ago
  > 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.
  - lenkite 9mo ago
    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 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 https://github.com/rust-lang/rust/issues/63818
    - aw1621107 9mo ago
      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, is an intentional implementation decision and the devs have not indicated any interest in fixing it so far.
      - tptacek 9mo ago
        Neither set of issues is apposite to MemorySafety.org. The whole thing is just a dumb language war spat.
deleted 9mo ago
[deleted]

by codys 9mo ago

lenkite 9mo ago

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 https://rfd.shared.oxide.computer/rfd/0609

aw1621107 9mo ago
> 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.
- lenkite 9mo ago
  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 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 https://github.com/rust-lang/rust/issues/63818
  - aw1621107 9mo ago
    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, is an intentional implementation decision and the devs have not indicated any interest in fixing it so far.
    - tptacek 9mo ago
      Neither set of issues is apposite to MemorySafety.org. The whole thing is just a dumb language war spat.

deleted 9mo ago

[deleted]