3 ms·

> [It's not true] that unsafe somehow "encapsulates" memory bugs. I believe this real-life, 4-year, 1.5 million-line-of-code experiment disagrees with you dire

> [It's not true] that unsafe somehow "encapsulates" memory bugs. I believe this real-life, 4-year, 1.5 million-line-of-code experiment disagrees with you directly [1] > In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety. [1] https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language...

Capricorn2481 3y ago
I don't think you really understood my comment. unsafe fn create_null_pointer() -> *const u32 { std::ptr::null() } fn main() { let ptr = unsafe { create_null_pointer() }; // Dereferencing the null pointer outside of unsafe code let value = unsafe { *ptr }; println!("Value: {}", value); } This will segfault, and the compiler won't warn you about it, even though an error didn't actually happen until you printed the value in "safe" code What this article is getting at is that the unsafe keyword highlights pieces of code that Google scrutinizes, not that it has functionality that "magically" encapsulates memory bugs. And yes, it's a lot better than C++. But you still need to be aware this can happen and not assume you're safe All unsafe does is shut off the compiler for sections of the code. You can write code in an unsafe block that bubbles outside of the scope of "unsafe."*
- davidatbu 3y ago
  Ah, I get what you're saying now. When you said > "you'd be surprised how many Rust engineers think unsafe somehow 'encapsulates' memory bugs inside the block itself," you essentially mean: > "you'd be surprised how many Rust engineers think that they can use unsafe without regard as to whether they are maintaining Rust's safety invariants by hand in their unsafe blocks." Yes, I do find that surprising!

Capricorn2481 3y ago

I don't think you really understood my comment. unsafe fn create_null_pointer() -> *const u32 { std::ptr::null() } fn main() { let ptr = unsafe { create_null_pointer() }; // Dereferencing the null pointer outside of unsafe code let value = unsafe { *ptr }; println!("Value: {}", value); } This will segfault, and the compiler won't warn you about it, even though an error didn't actually happen until you printed the value in "safe" code What this article is getting at is that the unsafe keyword highlights pieces of code that Google scrutinizes, not that it has functionality that "magically" encapsulates memory bugs. And yes, it's a lot better than C++. But you still need to be aware this can happen and not assume you're safe All unsafe does is shut off the compiler for sections of the code. You can write code in an unsafe block that bubbles outside of the scope of "unsafe."*

davidatbu 3y ago
Ah, I get what you're saying now. When you said > "you'd be surprised how many Rust engineers think unsafe somehow 'encapsulates' memory bugs inside the block itself," you essentially mean: > "you'd be surprised how many Rust engineers think that they can use unsafe without regard as to whether they are maintaining Rust's safety invariants by hand in their unsafe blocks." Yes, I do find that surprising!