4 ms·
Resource leaks have nothing to do with safety. That's true both for memory safety and i/o safety. See for yourself with `mem::forget(File::open(...)?)`
by fallingsquirrel 2y ago
Resource leaks have nothing to do with safety. That's true both for memory safety and i/o safety. See for yourself with `mem::forget(File::open(...)?)`
- ekidd 2y agoYeah, "safe Rust" is officially allowed to leak memory and other resources. - The easiest way to do this is mem::forget, a safe function which exists to leak memory deliberately. - The most common real way to leak memory is to create a loop using the Rc<T> or Arc<T> reference count types. I've never seen this in any of my company's Rust code, but we don't write our own cyclic data structures, either. This is either a big deal to you, or a complete non-issue, depending on your program architecture. Basically, "safe Rust" aims to protect you from memory corruption, undefined behavior, and data races between threads. It does not protect you from leaks, other kinds of race conditions, or (obviously) logic bugs.
- chubot 2y agoYeah the article is giving what looks like a bad definition: According to: https://rust-lang.github.io/rfcs/3128-io-safety.html https://rust-lang.github.io/rfcs/3128-io-safety.html Rust’s standard library almost provides I/O safety, a guarantee that if one part of a program holds a raw handle privately, other parts cannot access it. According to the article: I/O Safety: Ensuring that accepted TCP streams are properly closed without leaking connections. These are not the same definition. As I've mentioned several times [1], in Rust, the word "safety" is being abused to the point of causing confusion, and it looks like this is another instance of that. [1] https://news.ycombinator.com/item?id=31726723 https://news.ycombinator.com/item?id=31726723
- ethegwo 2y agoThank you! I will update the post and fix it.