4 ms·

The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior. A lot of Rust’s std and li

The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior. A lot of Rust’s std and library ecosystem provides safe wrappers around underlying unsafe C APIs, by cleverly using borrow semantics and performing additional runtime checks. The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is completely fine, that’s not considered unsafe. Presumably, the C++ wrappers suggested here would not even be safe in that sense. They would use a lot of pointers, and cause UB if passed the wrong one. The article argues that using unsafe correctly is impractical for Chromium because basically every Rust function would have to be marked unsafe to call into these raw C++ APIs. Whether that’s the right call, I don’t know. I see the practical argument, but I also think that a lot of common Rust idioms, especially around memory management, depend on these safety guarantees. For example, field destruction order in Rust is weird and you often don’t control it as carefully as you would in C++. That’s usually fine in normal Rust code, but might not be if lots of marked-as-safe-but-actually-unsafe code is flying around.

steveklabnik 6y ago
> For example, field destruction order in Rust is weird and you often don’t control it as carefully as you would in C++. This is well-defined, as being dropped in the order that they are declared.
- codeflo 6y ago
  I didn't want to suggest it's undefined, I said weird. In C++, it's reverse declaration order, and that's important because destruction exactly mirrors construction. Arguably, Rust is completely wrong here, but my experience is that this problem doesn't come up in idiomatic Rust all that often because fields can't depend on each other anyway. And I'm wildly speculating of course, but something like that might be more of an issue if a lot of unsafe C++ objects are instantiated from within Rust.
  - steveklabnik 6y ago
    I see, I misunderstood how you said that, but I get it now. :) Sorry about that! Yeah, the fact that it's the opposite in C++ was a huge point of contention before we defined it; changing what was there risked breaking a lot of code, and there are good reasons for either order. But yeah, I had to go and look at the RFC for exactly the reasons you state; it just isn't normal to care about this at all, so it's easy to not remember.
  - saurik 6y ago
    Just because fields can't depend on each other in code doesn't mean that the side effects of those fields don't matter: Rust is only guaranteeing memory safety, not semantic safety... like, if you are tracking file handles or networked objects or bicycle messengers, it can easily (and even often) be very important that objects deconstruct in the reverse stacking order of their construction. I am so glad I read your comment here as I could easily see myself one day starting to use Rust and going insane from this decision :(. (The more I think about this the more concerned I honestly am as I am not even sure how to implement many paradigms correctly without this basic deconstruction stacking order property.)
    - kbenson 6y ago
      > The more I think about this the more concerned I honestly am as I am not even sure how to implement many paradigms correctly without this basic deconstruction stacking order property Don't you just define a destructor[1] and make it explicit? Or maybe I'm missing something subtle here? 1: https://doc.rust-lang.org/reference/destructors.html https://doc.rust-lang.org/reference/destructors.html
kbenson 6y ago
> The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is completely fine, that’s not considered unsafe. Yes, because "safety" in English is not analogous to "unsafe" in Rust in any real manner. They are linked only in the loosest conceptual way. Rust's "safety" and "unsafe" are well defined and exact, and can be objectively determined. In the English language it is by its nature subjective. > The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior. That is, specifically AFAIK, not what it means in Rust. It's well defined there, so there's no need to resort to "the usual understanding". This causes a lot of confusion, but it doesn't need to. If someone is talking about the unsafe keyword in Rust, they're talking about Rust's definition of it and what it entails, or they're using incorrect terminology. > Presumably, the C++ wrappers suggested here would not even be safe in that sense. They would use a lot of pointers, and cause UB if passed the wrong one. Then there's not a lot of point in using Rust if they refuse to change that usage. It's not about using Rust to check off a box that you use some buzzword technology, it's about leveraging what it can provide that other languages can't, or can't do as well. If someone finally decides to put a firewall in front of a server but decides its' too hard to actually limit traffic in any way so allows 0.0.0.0/0 any port, you don't congratulate them on their firewall, you tell them they just wasted everyone's time and money. > The article argues that using unsafe correctly is impractical for Chromium because basically every Rust function would have to be marked unsafe to call into these raw C++ APIs. To my knowledge, the way Firefox did it was to pick a system or library, provide a Rust replacement that C/C++ could call, and allow it to be moved into place. That's sane. Using rust and C++ functions on the same memory and expecting Rust to deal with C++'s pointer shenanigans may not be, in the same way I wouldn't expect mixing small amounts of Java in the JVM into a big C++ would just work unless you had hard rules about who controlled what memory/objects and made sure you never broke them. I can't help but feel they're approach is likely to cause them more problems than needed because they're not willing to commit the sane minimal amount to make a lot of these problems not matter (replace a small self contained system). If they don't actually have any small self contained system, and they really are just passing stuff around and using some complex pointer control, and aren't willing to change that, maybe Rust isn't a good candidate to extend their project languages with.
- 6y ago

steveklabnik 6y ago

> For example, field destruction order in Rust is weird and you often don’t control it as carefully as you would in C++. This is well-defined, as being dropped in the order that they are declared.

codeflo 6y ago
I didn't want to suggest it's undefined, I said weird. In C++, it's reverse declaration order, and that's important because destruction exactly mirrors construction. Arguably, Rust is completely wrong here, but my experience is that this problem doesn't come up in idiomatic Rust all that often because fields can't depend on each other anyway. And I'm wildly speculating of course, but something like that might be more of an issue if a lot of unsafe C++ objects are instantiated from within Rust.
- steveklabnik 6y ago
  I see, I misunderstood how you said that, but I get it now. :) Sorry about that! Yeah, the fact that it's the opposite in C++ was a huge point of contention before we defined it; changing what was there risked breaking a lot of code, and there are good reasons for either order. But yeah, I had to go and look at the RFC for exactly the reasons you state; it just isn't normal to care about this at all, so it's easy to not remember.
- saurik 6y ago
  Just because fields can't depend on each other in code doesn't mean that the side effects of those fields don't matter: Rust is only guaranteeing memory safety, not semantic safety... like, if you are tracking file handles or networked objects or bicycle messengers, it can easily (and even often) be very important that objects deconstruct in the reverse stacking order of their construction. I am so glad I read your comment here as I could easily see myself one day starting to use Rust and going insane from this decision :(. (The more I think about this the more concerned I honestly am as I am not even sure how to implement many paradigms correctly without this basic deconstruction stacking order property.)
  - kbenson 6y ago
    > The more I think about this the more concerned I honestly am as I am not even sure how to implement many paradigms correctly without this basic deconstruction stacking order property Don't you just define a destructor[1] and make it explicit? Or maybe I'm missing something subtle here? 1: https://doc.rust-lang.org/reference/destructors.html https://doc.rust-lang.org/reference/destructors.html

kbenson 6y ago

> The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is completely fine, that’s not considered unsafe. Yes, because "safety" in English is not analogous to "unsafe" in Rust in any real manner. They are linked only in the loosest conceptual way. Rust's "safety" and "unsafe" are well defined and exact, and can be objectively determined. In the English language it is by its nature subjective. > The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior. That is, specifically AFAIK, not what it means in Rust. It's well defined there, so there's no need to resort to "the usual understanding". This causes a lot of confusion, but it doesn't need to. If someone is talking about the unsafe keyword in Rust, they're talking about Rust's definition of it and what it entails, or they're using incorrect terminology. > Presumably, the C++ wrappers suggested here would not even be safe in that sense. They would use a lot of pointers, and cause UB if passed the wrong one. Then there's not a lot of point in using Rust if they refuse to change that usage. It's not about using Rust to check off a box that you use some buzzword technology, it's about leveraging what it can provide that other languages can't, or can't do as well. If someone finally decides to put a firewall in front of a server but decides its' too hard to actually limit traffic in any way so allows 0.0.0.0/0 any port, you don't congratulate them on their firewall, you tell them they just wasted everyone's time and money. > The article argues that using unsafe correctly is impractical for Chromium because basically every Rust function would have to be marked unsafe to call into these raw C++ APIs. To my knowledge, the way Firefox did it was to pick a system or library, provide a Rust replacement that C/C++ could call, and allow it to be moved into place. That's sane. Using rust and C++ functions on the same memory and expecting Rust to deal with C++'s pointer shenanigans may not be, in the same way I wouldn't expect mixing small amounts of Java in the JVM into a big C++ would just work unless you had hard rules about who controlled what memory/objects and made sure you never broke them. I can't help but feel they're approach is likely to cause them more problems than needed because they're not willing to commit the sane minimal amount to make a lot of these problems not matter (replace a small self contained system). If they don't actually have any small self contained system, and they really are just passing stuff around and using some complex pointer control, and aren't willing to change that, maybe Rust isn't a good candidate to extend their project languages with.

6y ago