4 ms·

Transmuting an & to &mut is UB. - Transmuting an & to &mut is always UB. - No you can't do it. - No you're not special.

by runiq 5y ago

agalunar 5y ago
I remember reading this exact part of the 'nomicon and being really put off by it. I understand it's a joke, but it's a bit tasteless, and terribly condescending. I was surprised by how much it bothered me.
- whimsicalism 5y ago
  Goes to show that people can be offended by anything (:
  - agalunar 5y ago
    I'm not sure why it's surprising that some things might bother some people but not others. (?) Anyway, I thought the passage was an interesting reflection of the perspective of the 'nomicon authors. I'm fairly new to rust, and I've observed the culture – or at least, some part of the culture, and only as it's visible to newcomers – to be astonishingly friendly and helpful, but also sometimes, well, condescending. I sometimes get the occasional vibe of "this is bad and you want a bad thing" instead of "let me acknowledge your concern and here're options for addressing it" (with all the usual caveats: this attitude isn't by any means universal or even exemplified by a particular individual; obviously, the rust community doesn't owe anyone anything, so don't interpret the complaint as a demand; &c). I wonder whether other people have had a similar perception.
    - whimsicalism 5y ago
      I guess I am used to this sort of rhetoric around UB because it is just something that should not be done. I'm assuming you're not coming from C++?
      - agalunar 5y ago
        haha C++ is actually my primary language at work ^_^ and UB crosses my mind pretty often: there've been times I've read through the spec to make sure I avoid it. My feeling isn't really about `unsafe` in particular, though; it's more general. (Although I do see the potential conflation of "safe = correct, unsafe = incorrect" as problematic.)
        nyanpasu64 5y ago
        I view it more as "sound = correct, unsound = incorrect" (where unsound code is code that breaks Rust's rules and/or allows LLVM to generate malfunctioning code). The design goal of the language is that all code without unsafe is sound, and unsafe code I also feel "moralistic" about soundness, and I do see that in the community. You could argue that such moral thinking is misguided, IDK. And there are cases where people deliberately use UB to improve performance, like https://internals.rust-lang.org/t/bit-wise-reasoning-for-atomic-accesses/8853 https://internals.rust-lang.org/t/bit-wise-reasoning-for-ato... and https://internals.rust-lang.org/t/unordered-as-a-solution-to-bit-wise-reasoning-for-atomic-accesses/11079 https://internals.rust-lang.org/t/unordered-as-a-solution-to.... I'm not sure how the core team, or community, views such situations. Additionally, async fn desugarings and Tokio's intrusive linked lists (self-referential objects that can create &mut references) are unsound under Stacked Borrows (Rust's currently popular "formal memory model" for deciding what code/optimizations are sound), though I've heard promises that Stacked Borrows will be adjusted to declare these as sound.
- iudqnolq 5y ago
  I feel that way about the disclaimer on the homepage, but the transmuting to &mut disclaimer is literally true. Apologies if you're already familiar with this: It doesn't mean it's not sometimes necessary to have two `*mut T` to the same location, it's that the compiler makes specific assumptions about `&mut T` such that two &mut to the same location existing, even if never used, is UB. To work around this you need to stay in raw pointer land and use APIs like ptr::write.

Transmuting an & to &mut is UB. - Transmuting an & to &mut is always UB. - No you can't do it. - No you're not special.

by runiq 5y ago

Transmuting an & to &mut is UB. - Transmuting an & to &mut is always UB. - No you can't do it. - No you're not special.

I remember reading this exact part of the 'nomicon and being really put off by it. I understand it's a joke, but it's a bit tasteless, and terribly condescending. I was surprised by how much it bothered me.

whimsicalism 5y ago
Goes to show that people can be offended by anything (:
- agalunar 5y ago
  I'm not sure why it's surprising that some things might bother some people but not others. (?) Anyway, I thought the passage was an interesting reflection of the perspective of the 'nomicon authors. I'm fairly new to rust, and I've observed the culture – or at least, some part of the culture, and only as it's visible to newcomers – to be astonishingly friendly and helpful, but also sometimes, well, condescending. I sometimes get the occasional vibe of "this is bad and you want a bad thing" instead of "let me acknowledge your concern and here're options for addressing it" (with all the usual caveats: this attitude isn't by any means universal or even exemplified by a particular individual; obviously, the rust community doesn't owe anyone anything, so don't interpret the complaint as a demand; &c). I wonder whether other people have had a similar perception.
  - whimsicalism 5y ago
    I guess I am used to this sort of rhetoric around UB because it is just something that should not be done. I'm assuming you're not coming from C++?
    - agalunar 5y ago
      haha C++ is actually my primary language at work ^_^ and UB crosses my mind pretty often: there've been times I've read through the spec to make sure I avoid it. My feeling isn't really about `unsafe` in particular, though; it's more general. (Although I do see the potential conflation of "safe = correct, unsafe = incorrect" as problematic.)
      - nyanpasu64 5y ago
        I view it more as "sound = correct, unsound = incorrect" (where unsound code is code that breaks Rust's rules and/or allows LLVM to generate malfunctioning code). The design goal of the language is that all code without unsafe is sound, and unsafe code I also feel "moralistic" about soundness, and I do see that in the community. You could argue that such moral thinking is misguided, IDK. And there are cases where people deliberately use UB to improve performance, like https://internals.rust-lang.org/t/bit-wise-reasoning-for-atomic-accesses/8853 https://internals.rust-lang.org/t/bit-wise-reasoning-for-ato... and https://internals.rust-lang.org/t/unordered-as-a-solution-to-bit-wise-reasoning-for-atomic-accesses/11079 https://internals.rust-lang.org/t/unordered-as-a-solution-to.... I'm not sure how the core team, or community, views such situations. Additionally, async fn desugarings and Tokio's intrusive linked lists (self-referential objects that can create &mut references) are unsound under Stacked Borrows (Rust's currently popular "formal memory model" for deciding what code/optimizations are sound), though I've heard promises that Stacked Borrows will be adjusted to declare these as sound.
iudqnolq 5y ago
I feel that way about the disclaimer on the homepage, but the transmuting to &mut disclaimer is literally true. Apologies if you're already familiar with this: It doesn't mean it's not sometimes necessary to have two `*mut T` to the same location, it's that the compiler makes specific assumptions about `&mut T` such that two &mut to the same location existing, even if never used, is UB. To work around this you need to stay in raw pointer land and use APIs like ptr::write.