Rust NYC: Jon Gjengset - Demystifying unsafe code

แชร์
ฝัง
  • เผยแพร่เมื่อ 20 พ.ย. 2024

ความคิดเห็น • 16

  • @linkernick5379
    @linkernick5379 4 ปีที่แล้ว +50

    Jon's talks is the best advocacy we have in the Rust community, and thanks to them there will be the number of people wanting to create fast and reliable software with Rust.
    Thank you, Jon!

  • @thingsiplay
    @thingsiplay 3 ปีที่แล้ว +48

    In other languages people watch talks and learn about safe code.
    In Rust, we have to watch talks and learn about unsafe code.

  • @johanneslade2830
    @johanneslade2830 5 หลายเดือนก่อน +1

    Thank you so much for all the rust content you produce. It helped me understand a lot of the more complicated corners of rust❤

  • @dutchgh0st540
    @dutchgh0st540 4 ปีที่แล้ว +20

    The offset_of! example has another bug: A temporary reference to uninit memory.
    The `&raw` operator would fix both the UB described in the video, and the UB of the temporary reference to uninit memory

    • @willmcpherson2
      @willmcpherson2 4 ปีที่แล้ว +1

      To anyone else trying to get the offset of a field without UB, you need this crate:
      memoffset
      With this feature:
      unstable_raw
      And this feature gate:
      #![feature(raw_ref_macros)]
      Which means you'll need to use a nightly compiler.
      Bit of an unfortunate situation, but stabilisation efforts are ongoing: github.com/rust-lang/rust/issues/73394

  • @HyperManu
    @HyperManu 4 ปีที่แล้ว +31

    This guy is everywhere!

    • @non_complete
      @non_complete 4 ปีที่แล้ว +26

      And I'm absolutely delighted by that.

  • @errorlooo8124
    @errorlooo8124 4 ปีที่แล้ว +6

    What about ffi wrappers for c libraries when you have something like opengl which is a specification that garantuees things but you can't actually ever be fully sure the driver does them, should I rely on the spec when writing unsafe and blame the library if a break occurs because it doesn't follow the spec or should I try to wrap it a little more to make sure it doesn't blow the universe. I usually go with a combination depending on how useful a certain spec might be and how easy it is to misuse something and always when writing unsafe follow the spec that way you have a ice mix between safer unsafe and relying on the library( which I don't think is necesseraly a bad since you can review what it actually does and have garantuees from the spec, in contrast to a raw mem write which no matter how how hard you try without checks will never be fully safe) but I'm interested to hear what you guys think?

  • @KiffinGish
    @KiffinGish 4 ปีที่แล้ว

    Excellent overview, thanks. Unsafe has always been a bit of a mystery to me, but not anymore!

  • @luiswirth
    @luiswirth 4 ปีที่แล้ว +5

    Great content Jon as always!

  • @Arma5666
    @Arma5666 4 ปีที่แล้ว +1

    Well put together, informative talk!

  • @yushuh6278
    @yushuh6278 2 ปีที่แล้ว

    Great talk, nice shirt.

  • @babakabdollahi4123
    @babakabdollahi4123 3 ปีที่แล้ว

    Great talk, thanks.

  • @realsong-fake
    @realsong-fake 4 ปีที่แล้ว +6

    I'm curious about the people who claim never use unsafe. Do they just not use any unsafe from the std or core lib?

    • @whydoineedausername1386
      @whydoineedausername1386 4 ปีที่แล้ว +25

      They don't mean that they don't use anything that doesn't use unsafe. They just mean that they don't use it directly

    • @cat-.-
      @cat-.- 3 ปีที่แล้ว

      If someone don’t write unsafe and only use std unsafe then they can claim they never use unsafe