3 ms·

"Foreign functions are assumed to be unsafe so calls to them need to be wrapped with unsafe {} as a promise to the compiler that everything contained within tru

"Foreign functions are assumed to be unsafe so calls to them need to be wrapped with unsafe {} as a promise to the compiler that everything contained within truly is safe. C libraries often expose interfaces that aren't thread-safe, and almost any function that takes a pointer argument isn't valid for all possible inputs since the pointer could be dangling, and raw pointers fall outside of Rust's safe memory model." https://doc.rust-lang.org/nomicon/ffi.html https://doc.rust-lang.org/nomicon/ffi.html

wtetzner 7y ago
Not sure what you're getting at. Rust can't catch all bugs, so it's not worth having it to catch the ones it can?
- jstewartmobile 7y ago
  It is right there in black-and-white: 28 years of C to be interfaced with -> more FFI -> more unsafe blocks -> less that Rust can verify. I don't think there will be enough left outside of unsafe blocks to justify a second toolchain here. If the kernel were also in Rust, it would be a different story.
  - pornel 7y ago
    It's quite the opposite. Wrapping existing C code in Rust FFI can make it safer. Rust side can add missing type information to C interfaces. Things that are "RTFM" for C, such as thread safety of the types involved and which function arguments are borrowed/owned, can be expressed on the Rust side even for C code, and automatically enforced when it's used via FFI. This adds a layer of safety to existing C code.
    - jstewartmobile 7y ago
      "Using C libraries in a portable way involves a bit of work: finding the library on the system or building it if it's not available, checking if it is compatible, finding C headers and converting them to Rust modules, and giving Cargo correct linking instructions. Often every step of this is tricky..." Adding loads of complexity (i.e. more opportunities to screw something up) for a minor gain.
      - pornel 7y ago
        Note that this mess isn't created by Rust. The difficulty of building arbitrary C libraries on all platforms comes from C.
  - roca 7y ago
    Look at what the people working on Rust-in-Linux are actually doing. They are writing safe Rust wrappers around internal Linux APIs that drivers use and the Linux interfaces that drivers implement. Then you can write a driver in Rust that needs little or no unsafe code of its own. Better still, then you can write ten drivers in safe Rust reusing the same glue. And honestly, writing safe Rust wrappers around C APIs is not hard to do. The community has tons of experience with this. It does not wreck the coherence of the safe Rust code that uses those wrappers, like you seem to think.

wtetzner 7y ago

Not sure what you're getting at. Rust can't catch all bugs, so it's not worth having it to catch the ones it can?

jstewartmobile 7y ago
It is right there in black-and-white: 28 years of C to be interfaced with -> more FFI -> more unsafe blocks -> less that Rust can verify. I don't think there will be enough left outside of unsafe blocks to justify a second toolchain here. If the kernel were also in Rust, it would be a different story.
- pornel 7y ago
  It's quite the opposite. Wrapping existing C code in Rust FFI can make it safer. Rust side can add missing type information to C interfaces. Things that are "RTFM" for C, such as thread safety of the types involved and which function arguments are borrowed/owned, can be expressed on the Rust side even for C code, and automatically enforced when it's used via FFI. This adds a layer of safety to existing C code.
  - jstewartmobile 7y ago
    "Using C libraries in a portable way involves a bit of work: finding the library on the system or building it if it's not available, checking if it is compatible, finding C headers and converting them to Rust modules, and giving Cargo correct linking instructions. Often every step of this is tricky..." Adding loads of complexity (i.e. more opportunities to screw something up) for a minor gain.
    - pornel 7y ago
      Note that this mess isn't created by Rust. The difficulty of building arbitrary C libraries on all platforms comes from C.
- roca 7y ago
  Look at what the people working on Rust-in-Linux are actually doing. They are writing safe Rust wrappers around internal Linux APIs that drivers use and the Linux interfaces that drivers implement. Then you can write a driver in Rust that needs little or no unsafe code of its own. Better still, then you can write ten drivers in safe Rust reusing the same glue. And honestly, writing safe Rust wrappers around C APIs is not hard to do. The community has tons of experience with this. It does not wreck the coherence of the safe Rust code that uses those wrappers, like you seem to think.