4 ms·

To be fair, Vec::set_len bug in Rust was in 2021. And even then it had to be annotated as `unsafe`. It was then deprecated and a linter check was added: https:/

• Dr_Emann 6mo ago
  To be even fair-er, it wasn't actually memory unsafety, it was "just" unsoundness, there was a type, that IF you gave it an io reader implementation that was weird, that implementation could see uninit data, or expose uninit data elsewhere, but the only readers actually used were well behaved readers.
  • dapperdrake 6mo ago
    > well behaved readers. Around and around we go.
• orlp 6mo ago
  Vec::set_len is by no means deprecated. The lint you linked only covers a very specific unsound pattern using set_len.
  • kibwen 6mo ago
    Indeed, and it doesn't need to be deprecated, because it's an API explicitly designed to give you low-level control where you need it, and because it is appropriately defined as an `unsafe` function with documented safety invariants that must be manually upheld in order for usage to be memory-safe. The documentation also suggests several other (safe) functions that should be used instead when possible, and provides correct usage examples: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.set_len https://doc.rust-lang.org/std/vec/struct.Vec.html#method.set... .
    • bcjdjsndon 6mo ago
      > and because it is appropriately defined as an `unsafe` function with documented safety invariants that must be manually upheld in order for usage to be memory-safe. Didn't we learn from c, and the entire raison detre for rust, is that coders cannot be trusted to follow rules like this? If coders could "(document) safety invariants that must be manually upheld in order for usage to be memory-safe." there's be no need for Rust. This is the tautology underlying rust as I see it
      • kibwen 6mo ago
        No, this is mistaken. Rust provides `unsafe` functions for operations where memory-safety invariants must be manually upheld, and then forces callers to use `unsafe` blocks in order to call those functions, and then provides tooling for auditing unsafe blocks. Want to keep unsafe code out of your codebase? Then add `#![forbid(unsafe_code)]` to your crate root, and all unsafe code becomes a compiler error. Or you could add a check in your CI that prevents anyone from merging code that touches an unsafe block without sign-off from a senior maintainer. And/or you can add unit tests for any code that uses unsafe blocks and then run those tests under Miri, which will loudly complain if you perform any memory-unsafe operations. And you can add the `undocumented_unsafe_comment` lint in Clippy so that you'll never forget to document an unsafe block. Rust's culture is that unsafe blocks should be reserved for leaf nodes in the call graph, wrapped in safe APIs whose usage does not impose manual invariant management to downstream callers. Internally, those APIs represent a relatively miniscule portion of the codebase upon which all your verification can be focused. So you don't need to "trust" that coders will remember not to call unsafe functions needlessly, because the tooling is there to have your back.
        • bcjdjsndon 6mo ago
          > Want to keep unsafe code out of your codebase? And how is this feasible for a systems language? Rust becomes too impotent for its main use case if you only use safe rust. My original point still stands... Coders historically cannot be trusted to manually manage memory, unless they're rust coders apparently > So you don't need to "trust" that coders will remember not to call unsafe functions needlessly, because the tooling is there to have your back. By definition, it isn't possible for a tool to reason about unsafe code, otherwise the rust compiler would do it
  • joaohaas 6mo ago
    The specific use case the GNU maintainer listed followed this exact pattern.