3 ms·

I've found I constantly want to build off of an existing c or c++ library, so I need unsafe. I'm much less experienced than the people's code I'm using, and I'm

I've found I constantly want to build off of an existing c or c++ library, so I need unsafe. I'm much less experienced than the people's code I'm using, and I'm generally fine with "Rust protects against me, if the lib authors screwed up then bad things happen".

akiselev 6y ago
Absolutely. I don't base my choice of libraries solely on `unsafe` but at work the number of people who will review internal unsafe code is a fraction the number of people that would review even a moderately popular open source library.
kibwen 6y ago
IMO, using `unsafe` in order to do FFI is of a fundamentally different character than pure-Rust `unsafe`. To the compiler they're the same thing ("I can't verify this, be careful"), but to a reader/auditor the former is fairly reasonable ("I can see why it might be pragmatic to not have to rewrite this entire C program in Rust"), whereas the latter should raise eyebrows ("why, exactly, does this need to be `unsafe`?"). (That said, you obviously still have to be cautious when doing FFI.)
- iudqnolq 6y ago
  I thought the same, but it seems to me the logical conclusion is to mark "I've added no unsoundness compared to if you were using the library I'm binding to" as safe, and add in the docs homepage a general vibe of how sound the bound library is. When I suggested this on the Rust Reddit enough people thought this was a fundamental insult to the principles of what Rust means to them I decided not to do this.
  - timidger 6y ago
    Do you have a link to that discussion?
    - nicoburns 6y ago
      https://www.reddit.com/r/rust/comments/mxiufr/when_soundness_isnt_worth_it/ https://www.reddit.com/r/rust/comments/mxiufr/when_soundness... I was one of the people who commented on that post. My point was basically that "you need to uphold invariants in order for this to be sound" is exactly what `unsafe` means in Rust. So if you're wrapping a library that doesn't guarantee safety then you should mark it as unsafe (and there's nothing wrong with that). Rust library users will typically assume that they can do absolutely whatever they want with a safe interface and they cannot possibly cause memory safety issues, undefined behaviour, etc. A large part of the benefit of Rust is not even having to think about that. So it's important that libraries continue to stick to this convention.
  - mlindner 6y ago
    I think the discussion on Reddit you're referring to was saying something slightly more nuanced than that. The case I specifically remember was someone arguing that simply passing through a C library function call without making it clear certain invariants needed to be held in the calling Rust code to not cause undefined behavior was somehow "safe". If you're wrapping a C call with some Rust code and you don't ensure all the invariants that could crash the C code are taken care of, then your function is still unsafe. If you do ensure that all the invariants are taken care of that could crash the C code are taken care of, then it's fine to have it be safe.
nyanpasu64 6y ago
There are tools to automatically generate "safe" C++-Rust bindings (the intent being to restrict unsafety to trusting C++ code to be sound, without the risk of screwing up the bindings): https://github.com/dtolnay/cxx https://github.com/dtolnay/cxx and https://cxx.rs/ https://cxx.rs/. However, creating bindings without typing out `unsafe` was a controversial issue, discussed at https://www.reddit.com/r/rust/comments/ielvxu/the_cxx_debate/ https://www.reddit.com/r/rust/comments/ielvxu/the_cxx_debate... . Also there are tools to automatically parse C++ headers and turn them into cxx bindings: https://github.com/google/autocxx https://github.com/google/autocxx and https://docs.rs/autocxx/ https://docs.rs/autocxx/
- iudqnolq 6y ago
  When you use that sort of thing you pretty much always need to handwrite some bits as well.

akiselev 6y ago

Absolutely. I don't base my choice of libraries solely on `unsafe` but at work the number of people who will review internal unsafe code is a fraction the number of people that would review even a moderately popular open source library.

kibwen 6y ago

IMO, using `unsafe` in order to do FFI is of a fundamentally different character than pure-Rust `unsafe`. To the compiler they're the same thing ("I can't verify this, be careful"), but to a reader/auditor the former is fairly reasonable ("I can see why it might be pragmatic to not have to rewrite this entire C program in Rust"), whereas the latter should raise eyebrows ("why, exactly, does this need to be `unsafe`?"). (That said, you obviously still have to be cautious when doing FFI.)

iudqnolq 6y ago
I thought the same, but it seems to me the logical conclusion is to mark "I've added no unsoundness compared to if you were using the library I'm binding to" as safe, and add in the docs homepage a general vibe of how sound the bound library is. When I suggested this on the Rust Reddit enough people thought this was a fundamental insult to the principles of what Rust means to them I decided not to do this.
- timidger 6y ago
  Do you have a link to that discussion?
  - nicoburns 6y ago
    https://www.reddit.com/r/rust/comments/mxiufr/when_soundness_isnt_worth_it/ https://www.reddit.com/r/rust/comments/mxiufr/when_soundness... I was one of the people who commented on that post. My point was basically that "you need to uphold invariants in order for this to be sound" is exactly what `unsafe` means in Rust. So if you're wrapping a library that doesn't guarantee safety then you should mark it as unsafe (and there's nothing wrong with that). Rust library users will typically assume that they can do absolutely whatever they want with a safe interface and they cannot possibly cause memory safety issues, undefined behaviour, etc. A large part of the benefit of Rust is not even having to think about that. So it's important that libraries continue to stick to this convention.
- mlindner 6y ago
  I think the discussion on Reddit you're referring to was saying something slightly more nuanced than that. The case I specifically remember was someone arguing that simply passing through a C library function call without making it clear certain invariants needed to be held in the calling Rust code to not cause undefined behavior was somehow "safe". If you're wrapping a C call with some Rust code and you don't ensure all the invariants that could crash the C code are taken care of, then your function is still unsafe. If you do ensure that all the invariants are taken care of that could crash the C code are taken care of, then it's fine to have it be safe.

nyanpasu64 6y ago

There are tools to automatically generate "safe" C++-Rust bindings (the intent being to restrict unsafety to trusting C++ code to be sound, without the risk of screwing up the bindings): https://github.com/dtolnay/cxx https://github.com/dtolnay/cxx and https://cxx.rs/ https://cxx.rs/. However, creating bindings without typing out `unsafe` was a controversial issue, discussed at https://www.reddit.com/r/rust/comments/ielvxu/the_cxx_debate/ https://www.reddit.com/r/rust/comments/ielvxu/the_cxx_debate... . Also there are tools to automatically parse C++ headers and turn them into cxx bindings: https://github.com/google/autocxx https://github.com/google/autocxx and https://docs.rs/autocxx/ https://docs.rs/autocxx/

iudqnolq 6y ago
When you use that sort of thing you pretty much always need to handwrite some bits as well.