5 ms·

I've been planning on the cxx side to update my attribute macro to require `unsafe mod ffi {...}` or `unsafe extern "C" {...}` to signal presence of a proof obl

I've been planning on the cxx side to update my attribute macro to require `unsafe mod ffi {...}` or `unsafe extern "C" {...}` to signal presence of a proof obligation. I think that resolves all concerns from the January discussion, including viewpoints I don't necessarily agree with, without sacrificing any ease of use. Just haven't found time to make the compiler PR to allow exposing that syntax to macros yet, but I will.

fluffything 6y ago
That would completely resolve my concern about cxx. (i still think its a soundness bug in Rust that `extern { }` does not require unsafe since one can use it to trigger UB in safe Rust code)
- tick_tock_tick 6y ago
  What's your thoughts on #[no_mangle]? https://github.com/rust-lang/rust/issues/28179 https://github.com/rust-lang/rust/issues/28179 Frankly Rust values being a usable language too much to be 100% sound.
  - Jweb_Guru 6y ago
    I don't understand why you and others think that bringing up existing and irritating soundness holes in Rust is an argument for introducing new ones. Whether or not you think CXX exposes a sound API, it's a bad argument. This one is literally a bug that we can hopefully fix at some point, just like the floating point casts one was finally fixed.
  - fluffything 6y ago
    #[no_mangle], like many other Rust features, is unsound; that's a fact and not an opinion, there is a bug in the tracker open for it and labelled I-unsound (accepted as an unsound bug). It is a low priority issue, but will be fixed eventually. > Frankly Rust values being a usable language too much to be 100% sound. Rust has a really good track record of identifying, prioritizing, and fixing soundness bugs (e.g. it took 4 years of work to fix one floating-point soundness bug!). Many people continuously work on this at the academic, toolchain, and backend (llvm, crane lift) levels. There is also a lot of people continuously working on making sure that new language features like async/await, const generics, specialization, GATs, ... are sound. TBH i'm surprised to learn that not all Rust core members consider soundness to be a Rust core value. Maybe it isn't a Rust core value? (it is for me; without it, Rust makes no sense as a language to me)
steveklabnik 6y ago
I think that’s a fantastic compromise. I am 100% in agreement with you on this topic, FWIW.
- fluffything 6y ago
  How is that a compromise? The unsafe in `unsafe mod ffi { ... }` is literally the proof that all APIs exposed in the block are sound to call from safe Rust. It would only need to go hand in hand with a comment explaining why each API in the block is sound to call safely, and it allows users to not list unsound APIs in there, but wrap them manually when needed. Along with code that checks the C++ lib version, etc. to make sure that the proof are kept in sync with each version of the lib. That's completely different from not requiring any unsafe in the Rust side, and doing this en masse via bindgen.
  - cornstalks 6y ago
    > How is that a compromise? How is it not a compromise? Party A wanted (and implemented) something that didn't require `unsafe`. Party B wanted `unsafe` to be used. After much discussion, Party A concedes with allowing people to put `unsafe` in some of the code, and Party B concedes that putting it there is sufficient instead of requiring it to be strewn all over the place. Sounds like a (reasonable) compromise to me.
    - fluffything 6y ago
      Rust requires all safe Rust code to not have undefined behavior. Party A wanting safe Rust to have undefined behavior was wrong. Party A now adds unsafe to their API, so that undefined behavior only happens in unsafe Rust. I don't see the compromise anywhere. Party B told party A that they were wrong, and party A acknowledge it and fixed their crate.
      - cornstalks 6y ago
        You either haven't looked at how cxx works, or you're intentionally misrepresenting it. cxx generates code that uses `unsafe` blocks/functions. It then generates safe wrappers around those, which are what it exposes to users. It's no different then someone doing this: pub fn safe_fn() { extern { fn unsafe_fn(); } unsafe { unsafe_fn(); } } cxx just uses macros to generate that. You're welcome to have a different opinion on whether or not the user must pass an `unsafe` token to the macro. But that has no bearing on the code generated by the macro. Statements like "Party A wanting safe Rust to have undefined behavior was wrong" are just straight up incorrect.

fluffything 6y ago

That would completely resolve my concern about cxx. (i still think its a soundness bug in Rust that `extern { }` does not require unsafe since one can use it to trigger UB in safe Rust code)

tick_tock_tick 6y ago
What's your thoughts on #[no_mangle]? https://github.com/rust-lang/rust/issues/28179 https://github.com/rust-lang/rust/issues/28179 Frankly Rust values being a usable language too much to be 100% sound.
- Jweb_Guru 6y ago
  I don't understand why you and others think that bringing up existing and irritating soundness holes in Rust is an argument for introducing new ones. Whether or not you think CXX exposes a sound API, it's a bad argument. This one is literally a bug that we can hopefully fix at some point, just like the floating point casts one was finally fixed.
- fluffything 6y ago
  #[no_mangle], like many other Rust features, is unsound; that's a fact and not an opinion, there is a bug in the tracker open for it and labelled I-unsound (accepted as an unsound bug). It is a low priority issue, but will be fixed eventually. > Frankly Rust values being a usable language too much to be 100% sound. Rust has a really good track record of identifying, prioritizing, and fixing soundness bugs (e.g. it took 4 years of work to fix one floating-point soundness bug!). Many people continuously work on this at the academic, toolchain, and backend (llvm, crane lift) levels. There is also a lot of people continuously working on making sure that new language features like async/await, const generics, specialization, GATs, ... are sound. TBH i'm surprised to learn that not all Rust core members consider soundness to be a Rust core value. Maybe it isn't a Rust core value? (it is for me; without it, Rust makes no sense as a language to me)

steveklabnik 6y ago

I think that’s a fantastic compromise. I am 100% in agreement with you on this topic, FWIW.

fluffything 6y ago
How is that a compromise? The unsafe in `unsafe mod ffi { ... }` is literally the proof that all APIs exposed in the block are sound to call from safe Rust. It would only need to go hand in hand with a comment explaining why each API in the block is sound to call safely, and it allows users to not list unsound APIs in there, but wrap them manually when needed. Along with code that checks the C++ lib version, etc. to make sure that the proof are kept in sync with each version of the lib. That's completely different from not requiring any unsafe in the Rust side, and doing this en masse via bindgen.
- cornstalks 6y ago
  > How is that a compromise? How is it not a compromise? Party A wanted (and implemented) something that didn't require `unsafe`. Party B wanted `unsafe` to be used. After much discussion, Party A concedes with allowing people to put `unsafe` in some of the code, and Party B concedes that putting it there is sufficient instead of requiring it to be strewn all over the place. Sounds like a (reasonable) compromise to me.
  - fluffything 6y ago
    Rust requires all safe Rust code to not have undefined behavior. Party A wanting safe Rust to have undefined behavior was wrong. Party A now adds unsafe to their API, so that undefined behavior only happens in unsafe Rust. I don't see the compromise anywhere. Party B told party A that they were wrong, and party A acknowledge it and fixed their crate.
    - cornstalks 6y ago
      You either haven't looked at how cxx works, or you're intentionally misrepresenting it. cxx generates code that uses `unsafe` blocks/functions. It then generates safe wrappers around those, which are what it exposes to users. It's no different then someone doing this: pub fn safe_fn() { extern { fn unsafe_fn(); } unsafe { unsafe_fn(); } } cxx just uses macros to generate that. You're welcome to have a different opinion on whether or not the user must pass an `unsafe` token to the macro. But that has no bearing on the code generated by the macro. Statements like "Party A wanting safe Rust to have undefined behavior was wrong" are just straight up incorrect.