3 ms·

Sure, but safe Rust functions can _always_ be used safely. If your function cannot always be used safely, either it is an `unsafe` Rust function, or your progra

Sure, but safe Rust functions can _always_ be used safely. If your function cannot always be used safely, either it is an `unsafe` Rust function, or your program is broken according to the Rust spec. Publishing safe Rust APIs that are _intentionally_ unsound should at best be warned about to any other crate that depends on it. Ideally, those authors and their crate would simply be banned.

Ygg2 6y ago
And I explained. Either you change the C++ lib to not behave unsafely for inputs. Or you manually change the binding to keep the invariant. The assumption behind linking to C++ code is that it doesn't contain unsoundness. If it does the library was fucked way before.
- fluffything 6y ago
  I agree with you. But this discussion is about a tool that: * does not change the C++ code to behave correctly for all inputs * does not (and technically cannot) generate safe Rust bindings that keep the invariant (the bindings are automatically generated under the assumption that all C++ code is safe for all inputs).
  - the_mitsuhiko 6y ago
    It seems it’s quite an absolutist way to look at safety. It establishes that nothing is allowed to ask a user to proof safety unless the unsafe keyword is used somewhere. I think this is already invalidated by countless code generation and build scripts.
    - Jweb_Guru 6y ago
      The use of the unsafe keyword is how Rust's "absolutist" view is made practical... the obligation to write an extra seven to nine characters is pretty minimal compared to the burden of an actual proof. "Some automated build script probably don't respect that" isn't a great argument against that standard, I think, especially with the push to sandbox build scripts and procedural macros showing that people are still quite concerned about safety in those areas (I know you're referring to the code they generate and not the scripts themselves, but I see these as related issues of trust).
      - Ygg2 6y ago
        But the thing is, unsafe was never absolutist. Even regular safe Rust assumes you use unsafe in a proper manner. This build tool assumes your C++ code is safe enough to wrap around unsafe trivially.
        Jweb_Guru 6y ago
        Regular Rust assumes that you use unsafe in a proper manner, but still asks you to mark functions that can cause memory unsafety with the wrong inputs as unsafe. This is so people know what code to audit. If you don't do this (or at least, mark something in the module as unsafe), it's considered a bug in your library. Among other things, this kind of clear isolation boundary makes it obvious where your proof obligations are and consequently which code you can ignore when debugging undefined behavior (code outside the unsafe module is not responsible for the unsafety no matter what weird input it provides). This build tool, as first proposed, knowingly exposed macros that can cause memory unsafety with the wrong inputs, without making you write unsafe. If a build tool makes assumptions like "you probably know what you're doing with that C++ code" without asking you to write unsafe, it is just as wrong as an implementation of unchecked indexing that wasn't marked unsafe (because "you'll probably know not to use this unless you're really in bounds."). It is clear that you consider this a trivial matter, but many people very heavily involved in the Rust community (including the people working on its soundness proofs) do not.
        Ygg2 6y ago
        > knowingly exposed macros that can cause memory unsafety with the wrong inputs, This was done to deal with remarks Chromium devs had against Rust C++ binding. In lieu of that it's liberal treatment of unsafe is understandable.
        Jweb_Guru 6y ago
        With all due respect, "Chromium devs wanted feature X" does not make it a good idea. Servo devs wanted features that would have made Rust worse, too.
  - Ygg2 6y ago
    Yes. And? You seem to forget famous saying. Perfect is the enemy of good. Rust std wasn't yet verified to not contain unsafe behavior. In fact, some modelling discovered and fixed unsafe behavior in Rust std libs. Same happens here. If you discover that for inputs you have unsafe behavior calling ffi, you uncapsulate it in way that prevents misuses or fix in source ffi lib.

Ygg2 6y ago

And I explained. Either you change the C++ lib to not behave unsafely for inputs. Or you manually change the binding to keep the invariant. The assumption behind linking to C++ code is that it doesn't contain unsoundness. If it does the library was fucked way before.

fluffything 6y ago
I agree with you. But this discussion is about a tool that: * does not change the C++ code to behave correctly for all inputs * does not (and technically cannot) generate safe Rust bindings that keep the invariant (the bindings are automatically generated under the assumption that all C++ code is safe for all inputs).
- the_mitsuhiko 6y ago
  It seems it’s quite an absolutist way to look at safety. It establishes that nothing is allowed to ask a user to proof safety unless the unsafe keyword is used somewhere. I think this is already invalidated by countless code generation and build scripts.
  - Jweb_Guru 6y ago
    The use of the unsafe keyword is how Rust's "absolutist" view is made practical... the obligation to write an extra seven to nine characters is pretty minimal compared to the burden of an actual proof. "Some automated build script probably don't respect that" isn't a great argument against that standard, I think, especially with the push to sandbox build scripts and procedural macros showing that people are still quite concerned about safety in those areas (I know you're referring to the code they generate and not the scripts themselves, but I see these as related issues of trust).
    - Ygg2 6y ago
      But the thing is, unsafe was never absolutist. Even regular safe Rust assumes you use unsafe in a proper manner. This build tool assumes your C++ code is safe enough to wrap around unsafe trivially.
      - Jweb_Guru 6y ago
        Regular Rust assumes that you use unsafe in a proper manner, but still asks you to mark functions that can cause memory unsafety with the wrong inputs as unsafe. This is so people know what code to audit. If you don't do this (or at least, mark something in the module as unsafe), it's considered a bug in your library. Among other things, this kind of clear isolation boundary makes it obvious where your proof obligations are and consequently which code you can ignore when debugging undefined behavior (code outside the unsafe module is not responsible for the unsafety no matter what weird input it provides). This build tool, as first proposed, knowingly exposed macros that can cause memory unsafety with the wrong inputs, without making you write unsafe. If a build tool makes assumptions like "you probably know what you're doing with that C++ code" without asking you to write unsafe, it is just as wrong as an implementation of unchecked indexing that wasn't marked unsafe (because "you'll probably know not to use this unless you're really in bounds."). It is clear that you consider this a trivial matter, but many people very heavily involved in the Rust community (including the people working on its soundness proofs) do not.
        Ygg2 6y ago
        > knowingly exposed macros that can cause memory unsafety with the wrong inputs, This was done to deal with remarks Chromium devs had against Rust C++ binding. In lieu of that it's liberal treatment of unsafe is understandable.
        Jweb_Guru 6y ago
        With all due respect, "Chromium devs wanted feature X" does not make it a good idea. Servo devs wanted features that would have made Rust worse, too.
- Ygg2 6y ago
  Yes. And? You seem to forget famous saying. Perfect is the enemy of good. Rust std wasn't yet verified to not contain unsafe behavior. In fact, some modelling discovered and fixed unsafe behavior in Rust std libs. Same happens here. If you discover that for inputs you have unsafe behavior calling ffi, you uncapsulate it in way that prevents misuses or fix in source ffi lib.