4 ms·

> it crashes because of Rust ownership rules Ownership rules exist only at compile time and are not the reason it crashes at runtime.

logicprog 3y ago
Unless it's using e.g. RefCells to enforce them at runtime
remram 3y ago
Ownership rules describe an invariant that needs to be upheld both at compile time and run time for Rust code to function.
- wokwokwok 3y ago
  hmmm… Ownership rules can be arbitrarily violated by unsafe code which may cause a crash, or undefined behaviour but it does not prevent rust code from running. Many “violates single ownership rules” (eg. Concurrent mutable references) actually dont break rust, because the undefined behaviour on many platforms happen to be “eh, does whatever c does, which is actually fine”. It would be more correct to say that they must upheld to guarantee rust code functions correctly. However, segfaults come from memory corruption, which comes from unsafe code; probably use after drop. It doesnt usually come from violating single ownership rules, and usually it’s from “object was dropped because it was owned and you forgot to keep it alive across a callback boundary” just like c++ code with unique_ptr …but eh, whatever. The point is it crashes, which means the binding isn’t done correctly, whatever you call it. Lay blame where blame is due; the rust wrapper isn’t safe.
  - _flux 3y ago
    "crashing" could also mean a panic! caused by the runtime ensuring you have at most one mutable reference to an object.
  - remram 3y ago
    For one definition of "don't break". If you are UB, in my books (including the Rust book), you've broken. As per your comparison to C, you are mistaken, this would do whatever C does when it has incorrect `restrict` qualifiers. See how the book phrases it for yourself: https://doc.rust-lang.org/book/ch15-05-interior-mutability.html#enforcing-borrowing-rules-at-runtime-with-refcellt https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... The way RefCell works is not described as a similar but different set of rules or invariants, but as enforcing the same rules. Please do not ignore the compiler's assumptions in your own programs...
    - wokwokwok 3y ago
      You said, and I quote: > needs to be upheld both at compile time and run time for Rust code to function. That is not correct, in general, even if in some cases, it causes a crash via panic or segfault.
      - remram 3y ago
        A program that fails under some circumstances is a buggy program. The fact that it doesn't crash under some circumstances is no redeeming quality at all. I don't know what you are trying to argue here. This thread is already too deep. Ownership rules are not optional. Sorry?
        wokwokwok 3y ago
        You said, and I quote: > needs to be upheld both at compile time and run time for Rust code to function. That is not correct, in general, even if in some cases, it causes a crash via panic or segfault. /shrug If you want to argue a different point with someone, do it with someone else. I’m simply pointing out that you are categorically wrong in your statement.
        remram 3y ago
        I've explained and I've linked references, your last two comments say "not correct". If you don't want to argue don't, if you do please present arguments. You are not "pointing out" anything, you are stating against evidence.

logicprog 3y ago

Unless it's using e.g. RefCells to enforce them at runtime

remram 3y ago

Ownership rules describe an invariant that needs to be upheld both at compile time and run time for Rust code to function.

wokwokwok 3y ago
hmmm… Ownership rules can be arbitrarily violated by unsafe code which may cause a crash, or undefined behaviour but it does not prevent rust code from running. Many “violates single ownership rules” (eg. Concurrent mutable references) actually dont break rust, because the undefined behaviour on many platforms happen to be “eh, does whatever c does, which is actually fine”. It would be more correct to say that they must upheld to guarantee rust code functions correctly. However, segfaults come from memory corruption, which comes from unsafe code; probably use after drop. It doesnt usually come from violating single ownership rules, and usually it’s from “object was dropped because it was owned and you forgot to keep it alive across a callback boundary” just like c++ code with unique_ptr …but eh, whatever. The point is it crashes, which means the binding isn’t done correctly, whatever you call it. Lay blame where blame is due; the rust wrapper isn’t safe.
- _flux 3y ago
  "crashing" could also mean a panic! caused by the runtime ensuring you have at most one mutable reference to an object.
- remram 3y ago
  For one definition of "don't break". If you are UB, in my books (including the Rust book), you've broken. As per your comparison to C, you are mistaken, this would do whatever C does when it has incorrect `restrict` qualifiers. See how the book phrases it for yourself: https://doc.rust-lang.org/book/ch15-05-interior-mutability.html#enforcing-borrowing-rules-at-runtime-with-refcellt https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... The way RefCell works is not described as a similar but different set of rules or invariants, but as enforcing the same rules. Please do not ignore the compiler's assumptions in your own programs...
  - wokwokwok 3y ago
    You said, and I quote: > needs to be upheld both at compile time and run time for Rust code to function. That is not correct, in general, even if in some cases, it causes a crash via panic or segfault.
    - remram 3y ago
      A program that fails under some circumstances is a buggy program. The fact that it doesn't crash under some circumstances is no redeeming quality at all. I don't know what you are trying to argue here. This thread is already too deep. Ownership rules are not optional. Sorry?
      - wokwokwok 3y ago
        You said, and I quote: > needs to be upheld both at compile time and run time for Rust code to function. That is not correct, in general, even if in some cases, it causes a crash via panic or segfault. /shrug If you want to argue a different point with someone, do it with someone else. I’m simply pointing out that you are categorically wrong in your statement.
        remram 3y ago
        I've explained and I've linked references, your last two comments say "not correct". If you don't want to argue don't, if you do please present arguments. You are not "pointing out" anything, you are stating against evidence.