4 ms·

Casting mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object (I've seen this in a libra

Casting mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object (I've seen this in a library I tried using). In C++ casting a to a & is sound, and casting a * into a __restrict & might be unsound but restrict is so rarely used that it doesn't matter, whereas safe Rust nearly requires using &mut for mutating through a pointer. As for "compile-time memory safety inherently requires some limitations on programming style", I find compile-time lifetime safety to be a tradeoff, and often a net negative in not only performance but ease of programming for low-level code maintained by the same individual preserving a "theory" of the code over time (whereas I don't find compile-time bounds checking or thread safety to be a net negative to programmer experience nearly as often). And when I see people on crusades to stop programmers from writing code in unsafe languages (taking away programmers') ability to opt out of this tradeoff, I will stop at nothing to oppose these people.

deleted 4y ago
[deleted]
saghm 4y ago
> Casting mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object (I've seen this in a library I tried using). In C++ casting a to a & is sound, and casting a * into a __restrict & might be unsound but restrict is so rarely used that it doesn't matter, whereas safe Rust nearly requires using &mut for mutating through a pointer. I'm not 100% sure I know what you're trying to say here due to the autoformatting doing a number on your pointers, but if I'm correct, you're unhappy that being able to cast a raw pointer to a reference in Rust is unsafe when casting a pointer to a reference is sound in C++. What do you think should happen if the pointer is null? I don't think this is sound in C++ either; this simple example[1] segfaults for me, and I imagine that it's undefined behavior and that even a segfault isn't guaranteed. In Rust, you can call this method[2] to convert a raw mutable pointer to an Option of a mutable reference, which will contain None if the raw pointer is null. If you absolutely don't want to check that it's null, you can always unwrap that. Yes, `unsafe { foo.as_mut().unwrap() }` is more verbose than `foo as &mut _`, but it doesn't really strike me as controversial that the syntax is being optimized for other uses. > As for "compile-time memory safety inherently requires some limitations on programming style", I find compile-time lifetime safety to be a tradeoff, and often a net negative in not only performance but ease of programming for low-level code maintained by the same individual preserving a "theory" of the code over time (whereas I don't find compile-time bounds checking or thread safety to be a net negative to programmer experience nearly as often). I think that's a fair opinion to hold, even though I don't happen to agree with it personally. > And when I see people on crusades to stop programmers from writing code in unsafe languages (taking away programmers') ability to opt out of this tradeoff, I will stop at nothing to oppose these people. This is where you lose me. Developing a language with verbose for casting a possibly null pointer to a type that assumes it's not null is worth "stopping at nothing to oppose"? This sounds like you're the one going on a crusade to stop people from using languages you don't like. I don't really see why you'd assume that the people who develop Rust are the same ones who are evangelizing it in a way you don't like, but I guess that it doesn't matter if that's accurate or not if you're going to stop at nothing. [1]: https://godbolt.org/z/fvfc8cGda https://godbolt.org/z/fvfc8cGda [2]: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_mut https://doc.rust-lang.org/std/primitive.pointer.html#method....
- nyanpasu64 4y ago
  Rust is a language with advances and flaws compared to C++ (and presumably C too). I think Rust made some bad decisions to the point I would avoid using it for certain classes of software (generally low-level code, or emulators with complex shared mutability by design). My ire is directed at people like pcwalton who argue that it's wrong to design non-watertight-safe languages like Zig at all for application development, and mjg59 who argue unsafe language creators should be held legally liable for users harmed by programs written in those languages.
Rusky 4y ago
> Casting *mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object This is a very different statement than your first comment, and still wrong. Casting *mut to &mut is not, itself, unsound or UB- it is, for example, how `Mutex` and `RefCell` are implemented in the standard library! Alternating &muts is of course UB, but that has nothing to do with raw pointers- that's just the definition of &mut, however you obtain one. Even if it were not strictly UB, it would still need to be forbidden, because thread safety and library code (like `Mutex`) relies on it. > I find compile-time lifetime safety to be a tradeoff Yes, this is exactly what I said in the first place- my further point was that the other side of the trade-off is not fixed, and the ergonomics of raw pointers and interior mutability can, have, and will continue to improve over time. Or in other words, the Rust language developers are not "on a crusade to stop programmers from writing code in unsafe languages." Rather, they looked (and continue to look) for ways to expand the space of programs that can be written in safe languages. This is an important distinction, and you appear to be causing yourself a lot of grief ("stop at nothing"? really?) by conflating one with the other.
- nyanpasu64 4y ago
  I'll reconsider Rust as a low level language once improved raw pointer syntax becomes a reality. And regarding the crusade, I wasn't targeting Rust's creators (I think safe programs are currently too limited and unsafe too difficult to call "replacing C++" a success, but I can pick alternative low-level language when needed), but: > My ire is directed at people like pcwalton who argue that it's wrong to design non-watertight-safe languages like Zig at all for application development, and mjg59 who argue unsafe language creators should be held legally liable for users harmed by programs written in those languages.

deleted 4y ago

[deleted]

saghm 4y ago

> Casting mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object (I've seen this in a library I tried using). In C++ casting a to a & is sound, and casting a * into a __restrict & might be unsound but restrict is so rarely used that it doesn't matter, whereas safe Rust nearly requires using &mut for mutating through a pointer. I'm not 100% sure I know what you're trying to say here due to the autoformatting doing a number on your pointers, but if I'm correct, you're unhappy that being able to cast a raw pointer to a reference in Rust is unsafe when casting a pointer to a reference is sound in C++. What do you think should happen if the pointer is null? I don't think this is sound in C++ either; this simple example[1] segfaults for me, and I imagine that it's undefined behavior and that even a segfault isn't guaranteed. In Rust, you can call this method[2] to convert a raw mutable pointer to an Option of a mutable reference, which will contain None if the raw pointer is null. If you absolutely don't want to check that it's null, you can always unwrap that. Yes, `unsafe { foo.as_mut().unwrap() }` is more verbose than `foo as &mut _`, but it doesn't really strike me as controversial that the syntax is being optimized for other uses. > As for "compile-time memory safety inherently requires some limitations on programming style", I find compile-time lifetime safety to be a tradeoff, and often a net negative in not only performance but ease of programming for low-level code maintained by the same individual preserving a "theory" of the code over time (whereas I don't find compile-time bounds checking or thread safety to be a net negative to programmer experience nearly as often). I think that's a fair opinion to hold, even though I don't happen to agree with it personally. > And when I see people on crusades to stop programmers from writing code in unsafe languages (taking away programmers') ability to opt out of this tradeoff, I will stop at nothing to oppose these people. This is where you lose me. Developing a language with verbose for casting a possibly null pointer to a type that assumes it's not null is worth "stopping at nothing to oppose"? This sounds like you're the one going on a crusade to stop people from using languages you don't like. I don't really see why you'd assume that the people who develop Rust are the same ones who are evangelizing it in a way you don't like, but I guess that it doesn't matter if that's accurate or not if you're going to stop at nothing. [1]: https://godbolt.org/z/fvfc8cGda https://godbolt.org/z/fvfc8cGda [2]: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_mut https://doc.rust-lang.org/std/primitive.pointer.html#method....

nyanpasu64 4y ago
Rust is a language with advances and flaws compared to C++ (and presumably C too). I think Rust made some bad decisions to the point I would avoid using it for certain classes of software (generally low-level code, or emulators with complex shared mutability by design). My ire is directed at people like pcwalton who argue that it's wrong to design non-watertight-safe languages like Zig at all for application development, and mjg59 who argue unsafe language creators should be held legally liable for users harmed by programs written in those languages.

Rusky 4y ago

> Casting *mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object This is a very different statement than your first comment, and still wrong. Casting *mut to &mut is not, itself, unsound or UB- it is, for example, how `Mutex` and `RefCell` are implemented in the standard library! Alternating &muts is of course UB, but that has nothing to do with raw pointers- that's just the definition of &mut, however you obtain one. Even if it were not strictly UB, it would still need to be forbidden, because thread safety and library code (like `Mutex`) relies on it. > I find compile-time lifetime safety to be a tradeoff Yes, this is exactly what I said in the first place- my further point was that the other side of the trade-off is not fixed, and the ergonomics of raw pointers and interior mutability can, have, and will continue to improve over time. Or in other words, the Rust language developers are not "on a crusade to stop programmers from writing code in unsafe languages." Rather, they looked (and continue to look) for ways to expand the space of programs that can be written in safe languages. This is an important distinction, and you appear to be causing yourself a lot of grief ("stop at nothing"? really?) by conflating one with the other.

nyanpasu64 4y ago
I'll reconsider Rust as a low level language once improved raw pointer syntax becomes a reality. And regarding the crusade, I wasn't targeting Rust's creators (I think safe programs are currently too limited and unsafe too difficult to call "replacing C++" a success, but I can pick alternative low-level language when needed), but: > My ire is directed at people like pcwalton who argue that it's wrong to design non-watertight-safe languages like Zig at all for application development, and mjg59 who argue unsafe language creators should be held legally liable for users harmed by programs written in those languages.