4 ms·

I'm really surprised to read this, it's so obvious to me that what fluffything says is correct that I can't quite imagine what the counter-argument looks like.

by simias 6y ago

I'm really surprised to read this, it's so obvious to me that what fluffything says is correct that I can't quite imagine what the counter-argument looks like. I kinda feel like the original sin in this discussion is that "unsafe {}" should really have been called "safe {}" or "sound {}" since it's really the programmer telling the compiler "hey, this block is safe to run as-is, I've checked, trust me on that". An automatic C++ binding library is in no position to make this assertion. It's weird to quote the Holy Scripture back at you of all people but here it goes (emphasis mine): https://doc.rust-lang.org/beta/reference/behavior-considered-undefined.html https://doc.rust-lang.org/beta/reference/behavior-considered... > Rust code is incorrect if it exhibits any of the behaviors in the following list. This includes code within unsafe blocks and unsafe functions. unsafe only means that avoiding undefined behavior is on the programmer; it does not change anything about the fact that Rust programs must never cause undefined behavior. > It is the programmer's responsibility when writing unsafe code to ensure that any safe code interacting with the unsafe code cannot trigger these behaviors. unsafe code that satisfies this property for any safe client is called sound; if unsafe code can be misused by safe code to exhibit undefined behavior, it is unsound. This library generates safe bindings to unsafe FFI calls without actually checking that said code is safe to call that way. It's therefore totally unsound until proven otherwise. So what's the argument here? That the C++ code might be safe to call that way if we're lucky? I mean, sure, but how is that reasonable or practical? I definitely don't want a FFI library to tag functions as safe for me before I had the time to validate it, it seems to easy to let something bad slip unnoticed. If the interface is unsafe it means that I need to review it and manually mark it as safe once I've taken due diligence and I can vouch that the interface is actually sound. And I definitely don't want a third-party crate to expose a safe-but-unsound Rust interface with a big disclaimer that "basically it's just raw calls to C++, make sure you use it right otherwise it's segfault time!". Again, it's mind boggling to me that this is controversial. It's not just bullshit language lawyering either, I think it's a terrible idea both in theory and in practice. I can already see the Rust crates leaking unsound """safe""" interfaces left and right because they're just a thin automatically-generated wrapper around C++ header files.

steveklabnik 6y ago
I wrote up a blog post about it, I linked to it in a sibling comment, I don't want to spam :) > So what's the argument here? That the C++ code might be safe to call that way if we're lucky? No, the argument is that we've checked that the C++ code is safe to call, just like any other FFI. We've reduced the boilerplate of doing so with a macro, just like any other boilerplate might be. > I definitely don't want a FFI library to tag functions as safe for me before I had the time to validate it, Do you validate every single unsafe code in every single library you use? Even the standard library? Every time? > And I definitely don't want a third-party crate to expose a safe-but-unsound Rust interface with a big disclaimer that "basically it's just raw calls to C++, make sure you use it right otherwise it's segfault time!". I do not either, but CXX doesn't change this in any meaningful way. This could still happen before.
- tonyhb 6y ago
  > Do you validate every single unsafe code in every single library you use? Even the standard library? Every time? Nope. But if I use a rust library, the compiler will do that for me. If it's Rust. And not CXX. I shouldn't have to in Rust. That's... the central premise here. Usage of unsafe code should say that it's unsafe.
- fluffything 6y ago
  > Do you validate every single unsafe code in every single library you use? Even the standard library? Every time? We don't need to? Rust's main soundness theorem says that if a safe Rust API is sound, then safe Rust code using it is sound. So the only thing we need to check is that the unsafe code that _we_ write is sound, and we 100% do this all the way for the standard library. In the standard library _every_ unsafe block has a comment explaining why the "user-provided soundness proof" that they represent is correct. We even have a linter that actually rejects PRs that add unsafe blocks to the standard library without such comments. > Do you validate every single unsafe code in every single library you use? Even the standard library? Every time? Soundness is IMO Rust's main feature and its main core value, and is more important than other Rust core values like, e.g., zero-overhead abstractions, which are also extremely important. Soundness is what enables "Hack without fear", "no segfaults", "refactor without fear", cargo ("large scale software without fear"), crates.io ("using other people's libraries without fear")... and it's what sets Rust apart from unsound-by-design languages like D, Nim, Zig, C, C++, etc. I haven't read the book in a long time, but the documentation I do read (nomicon, spec, unsafe code guidelines, issue tracker, internals) makes it very clear that making sure that unsafe Rust code is correct is critical for the ecosystem and for users to benefit from the main advantages Rust has to offer.

by simias 6y ago

steveklabnik 6y ago

I wrote up a blog post about it, I linked to it in a sibling comment, I don't want to spam :) > So what's the argument here? That the C++ code might be safe to call that way if we're lucky? No, the argument is that we've checked that the C++ code is safe to call, just like any other FFI. We've reduced the boilerplate of doing so with a macro, just like any other boilerplate might be. > I definitely don't want a FFI library to tag functions as safe for me before I had the time to validate it, Do you validate every single unsafe code in every single library you use? Even the standard library? Every time? > And I definitely don't want a third-party crate to expose a safe-but-unsound Rust interface with a big disclaimer that "basically it's just raw calls to C++, make sure you use it right otherwise it's segfault time!". I do not either, but CXX doesn't change this in any meaningful way. This could still happen before.

tonyhb 6y ago
> Do you validate every single unsafe code in every single library you use? Even the standard library? Every time? Nope. But if I use a rust library, the compiler will do that for me. If it's Rust. And not CXX. I shouldn't have to in Rust. That's... the central premise here. Usage of unsafe code should say that it's unsafe.
fluffything 6y ago
> Do you validate every single unsafe code in every single library you use? Even the standard library? Every time? We don't need to? Rust's main soundness theorem says that if a safe Rust API is sound, then safe Rust code using it is sound. So the only thing we need to check is that the unsafe code that _we_ write is sound, and we 100% do this all the way for the standard library. In the standard library _every_ unsafe block has a comment explaining why the "user-provided soundness proof" that they represent is correct. We even have a linter that actually rejects PRs that add unsafe blocks to the standard library without such comments. > Do you validate every single unsafe code in every single library you use? Even the standard library? Every time? Soundness is IMO Rust's main feature and its main core value, and is more important than other Rust core values like, e.g., zero-overhead abstractions, which are also extremely important. Soundness is what enables "Hack without fear", "no segfaults", "refactor without fear", cargo ("large scale software without fear"), crates.io ("using other people's libraries without fear")... and it's what sets Rust apart from unsound-by-design languages like D, Nim, Zig, C, C++, etc. I haven't read the book in a long time, but the documentation I do read (nomicon, spec, unsafe code guidelines, issue tracker, internals) makes it very clear that making sure that unsafe Rust code is correct is critical for the ecosystem and for users to benefit from the main advantages Rust has to offer.