3 ms·

We already had this debate many times. One of the last ones was the actix debacle, which was contained and accidental and ended up badly. This is IMO infinite

We already had this debate many times. One of the last ones was the actix debacle, which was contained and accidental and ended up badly. This is IMO infinitely worse.

steveklabnik 6y ago
I think they are categorically different debates.
- fluffything 6y ago
  To me they are categorically identical. Rust code author knowingly exposes unsound safe Rust APIs. The details are different. Actix did so in their own project and were willing to fix it (the debacle was mostly social, and in some sense even accidental), while here exposing unsound safe Rust APIs is the whole raison d'etre of the project. AutoCXX doesn't even check that the underlying C++ code does not change. So even if an autogenerated safe Rust API happens to be "accidentally safe", that can change any time without Rust users knowing.
  - steveklabnik 6y ago
    > Rust code author knowingly exposes unsound safe Rust APIs. This is where we disagree. I 100% agree that knowingly exposing an unsound API to safe Rust is a bad thing. However, what I see is the user of cxx/autocxx saying "I am asserting that this API is sound." > AutoCXX doesn't even check that the underlying C++ code does not change This is no different than any other Rust code calling into C++ code. The author has to declare that they believe it is safe either way.
    - fluffything 6y ago
      > However, what I see is the user of cxx/autocxx saying "I am asserting that this API is sound." And since the API of this library allows this assertion to be performed in safe Rust code, when it fails, safe Rust code has UB, which according to the Rust language reference makes the API of this crate unsound. Unsound safe Rust APIs are broken Rust code. The Rust language spec and toolchain make no guarantees about what the behavior of these APIs is. So that's what I see here. Just another safe Rust API that is broken by design. Maybe with the twist that this crate is actually a factory to generates thousands of those broken safe Rust APIs in masse, which kind of makes it worse than your usual "broken API" bug (which is what these are, these are soundness bugs in Rust libraries).
      - steveklabnik 6y ago
        > this assertion to be performed in safe Rust code, This assertion is always performed in safe Rust code. That's how you turn unsafe code into safe code: you write "unsafe { }" in safe code. That this does this in the body of a macro is not material. (I know you disagree and don't think we're going to get anywhere, and frankly, find your aggressiveness really offputting.)
        fluffything 6y ago
        > This assertion is always performed in safe Rust code. Safe Rust code performs these assertions by using the "unsafe" keyword. This library API allows safe Rust to perform these assertions _without_ writing "unsafe". That's the problem.
        steveklabnik 6y ago
        Do you think that macros should treat unsafe blocks in their body as a compiler error? Because that's what this boils down to. If so, why? How is that materially different from calling a function with unsafe in its body? If not, why is this particular macro different?
        fluffything 6y ago
        > Do you think that macros should treat unsafe blocks in their body as a compiler error? No. Exported macros (as opposed to private ones) are only sound if they do not allow safe Rust to introduce undefined behavior. Whether these macros use "unsafe" internally or not is irrelevant. For example, `pin_mut!` uses unsafe internally, but it does not allow safe Rust calling it to introduce UB. A macro that allows safe Rust to introduce undefined behavior is unsound. An example of such an unsound macro would be `offset_of!`. --- That is, I do not differentiate Rust abstractions when it comes to soundness. Whether its a function, a trait method, a macro, or a function pointer, it does not matter. If an abstraction its safe to use it shall not introduce UB. If it does, it is an unsound abstraction.
    - Dylan16807 6y ago
      > However, what I see is the user of cxx/autocxx saying "I am asserting that this API is sound." Right now that's very implicit, and I bet there are users of the library that don't think they're asserting that. They expect you to follow the documented rules about invariants. Requiring people to write 'unsafe' at the import site makes that a lot clearer, but if it's mandatory then people are probably going to write it whether the API is sound or not. I'd be more comfortable if you could either declare an API sound when you import it or write 'unsafe' everywhere you call it.

We already had this debate many times. One of the last ones was the actix debacle, which was contained and accidental and ended up badly. This is IMO infinitely worse.

steveklabnik 6y ago

I think they are categorically different debates.

fluffything 6y ago
To me they are categorically identical. Rust code author knowingly exposes unsound safe Rust APIs. The details are different. Actix did so in their own project and were willing to fix it (the debacle was mostly social, and in some sense even accidental), while here exposing unsound safe Rust APIs is the whole raison d'etre of the project. AutoCXX doesn't even check that the underlying C++ code does not change. So even if an autogenerated safe Rust API happens to be "accidentally safe", that can change any time without Rust users knowing.
- steveklabnik 6y ago
  > Rust code author knowingly exposes unsound safe Rust APIs. This is where we disagree. I 100% agree that knowingly exposing an unsound API to safe Rust is a bad thing. However, what I see is the user of cxx/autocxx saying "I am asserting that this API is sound." > AutoCXX doesn't even check that the underlying C++ code does not change This is no different than any other Rust code calling into C++ code. The author has to declare that they believe it is safe either way.
  - fluffything 6y ago
    > However, what I see is the user of cxx/autocxx saying "I am asserting that this API is sound." And since the API of this library allows this assertion to be performed in safe Rust code, when it fails, safe Rust code has UB, which according to the Rust language reference makes the API of this crate unsound. Unsound safe Rust APIs are broken Rust code. The Rust language spec and toolchain make no guarantees about what the behavior of these APIs is. So that's what I see here. Just another safe Rust API that is broken by design. Maybe with the twist that this crate is actually a factory to generates thousands of those broken safe Rust APIs in masse, which kind of makes it worse than your usual "broken API" bug (which is what these are, these are soundness bugs in Rust libraries).
    - steveklabnik 6y ago
      > this assertion to be performed in safe Rust code, This assertion is always performed in safe Rust code. That's how you turn unsafe code into safe code: you write "unsafe { }" in safe code. That this does this in the body of a macro is not material. (I know you disagree and don't think we're going to get anywhere, and frankly, find your aggressiveness really offputting.)
      - fluffything 6y ago
        > This assertion is always performed in safe Rust code. Safe Rust code performs these assertions by using the "unsafe" keyword. This library API allows safe Rust to perform these assertions _without_ writing "unsafe". That's the problem.
        steveklabnik 6y ago
        Do you think that macros should treat unsafe blocks in their body as a compiler error? Because that's what this boils down to. If so, why? How is that materially different from calling a function with unsafe in its body? If not, why is this particular macro different?
        fluffything 6y ago
        > Do you think that macros should treat unsafe blocks in their body as a compiler error? No. Exported macros (as opposed to private ones) are only sound if they do not allow safe Rust to introduce undefined behavior. Whether these macros use "unsafe" internally or not is irrelevant. For example, `pin_mut!` uses unsafe internally, but it does not allow safe Rust calling it to introduce UB. A macro that allows safe Rust to introduce undefined behavior is unsound. An example of such an unsound macro would be `offset_of!`. --- That is, I do not differentiate Rust abstractions when it comes to soundness. Whether its a function, a trait method, a macro, or a function pointer, it does not matter. If an abstraction its safe to use it shall not introduce UB. If it does, it is an unsound abstraction.
  - Dylan16807 6y ago
    > However, what I see is the user of cxx/autocxx saying "I am asserting that this API is sound." Right now that's very implicit, and I bet there are users of the library that don't think they're asserting that. They expect you to follow the documented rules about invariants. Requiring people to write 'unsafe' at the import site makes that a lot clearer, but if it's mandatory then people are probably going to write it whether the API is sound or not. I'd be more comfortable if you could either declare an API sound when you import it or write 'unsafe' everywhere you call it.