5 ms·

> No need for the “unsafe” keyword unless something is known to be less safe than normal C++. > For a Rustacean, this is controversial - all C++ is unsafe! Is

> No need for the “unsafe” keyword unless something is known to be less safe than normal C++. > For a Rustacean, this is controversial - all C++ is unsafe! Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything? Unsafe is a Rust language definition, and defines whether the rust compiler can vouch for the safety of some code. As such, calling to a library in some other language will always be unsafe, by definition, because the Rust language cannot vouch for it. If it makes you feel better, replace "unsafe" in your head (or with a macro) with "rustc_cannot_vouch_for" and carry on with your day. It means the same thing, and isn't really telling you that your C++ code sucks even if it looks like it at first glance, so who cares? If you really want to reduce the unsafe keyword from being seen in most regular code, you create and interface that maps the C++ function and exposes it as a rust function, and you've hidden away your unsafe usage to one spot per function. If you have enough confidence in your C++ code, there's no downside to this (and if you don't, then maybe you shouldn't be complaining that unsafe is unneeded).

arcticbull 6y ago
> ... known to be less safe than normal C++. Oh... no, no, that's... very unsafe lol. Jokes aside, making that their #1 goal was very strange. Agreed it appears to be a fundamental misunderstanding of what "unsafe" means. It doesn't mean that it's literally not safe to call that function, just that it's unchecked. "unchecked" might be a better annotation come to think of it.
- kbenson 6y ago
  > "unchecked" might be a better annotation come to think of it. Yeah, it's come up before in discussions here. Depending on the context you're coming from/working in, unchecked either makes more sense, or less sense than unsafe. When working within Rust, unsafe makes sense, it maps to how people think about what they are doing, because rustc is checking everything. When working between Rust and other languages/libraries, it's a bit less accurate, and "unchecked" makes more sense.
- nicoburns 6y ago
  I don't think they're misunderstanding the meaning. I think there'a just so much "boilerplate unsafe" for such cases that it would distract from other uses which they could meaningfully audit.
- jevgeni 6y ago
  Sounds like an organizational way of seeming open to something, but making sure it never flies. “We are happy to empower our younger colleagues. We only ask they have 25 years of experience.”
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
codeflo 6y ago
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.
mths 6y ago
> If you really want to reduce the unsafe keyword from being seen in most regular code, you create and interface that maps the C++ function and exposes it as a rust function, and you've hidden away your unsafe usage to one spot per function. Isn't that what they did? Through the use of https://github.com/dtolnay/cxx https://github.com/dtolnay/cxx Agreed the article expressed the concern in a rather clumsy manner, but they seem to have a point for their particular use case, and they addressed it appropriately.
- kbenson 6y ago
  Yeah, in the end, they're taking a somewhat sane approach, it's just rather odd that they identify this as item number 1 that needs addressing. I'm not sure whether it's actually better to abstract all the unsafe away, or force it to shown where it's used. In one respect, they may be right, it might lesson the impact of unsafe and it gets used more freely. On the other, it also means that it's not necessarily immediately obvious when you're crossing boundaries, since the obvious bits and intentionally hidden away. Though I'll freely admit my initial responses were a bit hyperbolic and... testy. :)
  - ComputerGuru 6y ago
    I disagree, you can automatically expose any unsafe function with a wrapper _safe function that does nothing more than call the former (possibly also wrapping fundamentally unsafe types in arguments and return values) which makes it appear safe but that doesn’t make it sane. There would need to be domain understanding baked into each wrapper and some contract about what is happening on the other side of the ffi wall for it to qualify as both safe and sane, and I’m not sure their approach meets that high burden.
Impossible 6y ago
Yeah... The unsafe keyword is not unique to Rust either and exist in C# with similar semantics (although slightly different due to gc vs borrow checker memory management). One way to think of it is unsafe blocks effectively let you write C, with pointers and other memory unsafe operations inside of an otherwise safe language. This can be used for performance critical code (in a similar, but higher level, way as inline asm) but is primarily used to interface with unsafe C APIs (OS APIs, graphics APIs, etc) and libraries. Entirely agree that this is a misunderstanding.
emmelaich 6y ago
The Rust definition of 'unsafe' is very far from the everyday meaning. Yeah you can mentally substitute 'rustc_cannot_vouch_for' but why can't Rust use a word closer in meaning to that in the first place? We tend to misuse everyday meanings I think. I reminded of 1. the msdos warning that 'this program has used an illegal instruction and will be shut down' 2. That DNS names with underscore are 'illegal'. This one caused an amusing kerfuffle at one company I worked at. 3. That certain crypto algos are 'broken'
- powersnail 6y ago
  I'm reminded of "my phone has 64g of memory". It makes sense to a lay person, that memory would mean storage. This is inevitable. We either invent new words, or we use existing words from the natural language. The latter will always lead to confusion at some point, because the domain-specific concept doesn't exist in the rest of the world. To represent such a concept, a word would need to deviate from its everyday usage. I think Rust's "unsafe" is an okay choice; the "vouching" is a feature about memory safety after all.
- kbenson 6y ago
  > The Rust definition of 'unsafe' is very far from the everyday meaning. "safe" is entirely relative in it's everyday meaning. To one person skydiving is safe, to another it is extremely unsafe. When you're a child your parent will tell you what is safe or not, but what your parent considers safe is based on their personal definition of safety. The rust language will tell you if what you've done is safe based on its very well defined criteria for what that is, and won't let you proceed with something that doesn't match that criteria unless you vouch for it yourself. unsafe makes just as much sense here as any other word, it only seems a wrong fit when you look at it from a context it's not meant to be used in.
  - emmelaich 6y ago
    I'd suggest that 'unsafe' is quite far away from the opposite meaning of 'safe' in everyday language.
- tracker1 6y ago

arcticbull 6y ago

> ... known to be less safe than normal C++. Oh... no, no, that's... very unsafe lol. Jokes aside, making that their #1 goal was very strange. Agreed it appears to be a fundamental misunderstanding of what "unsafe" means. It doesn't mean that it's literally not safe to call that function, just that it's unchecked. "unchecked" might be a better annotation come to think of it.

kbenson 6y ago
> "unchecked" might be a better annotation come to think of it. Yeah, it's come up before in discussions here. Depending on the context you're coming from/working in, unchecked either makes more sense, or less sense than unsafe. When working within Rust, unsafe makes sense, it maps to how people think about what they are doing, because rustc is checking everything. When working between Rust and other languages/libraries, it's a bit less accurate, and "unchecked" makes more sense.
nicoburns 6y ago
I don't think they're misunderstanding the meaning. I think there'a just so much "boilerplate unsafe" for such cases that it would distract from other uses which they could meaningfully audit.
jevgeni 6y ago
Sounds like an organizational way of seeming open to something, but making sure it never flies. “We are happy to empower our younger colleagues. We only ask they have 25 years of experience.”

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

codeflo 6y ago

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.

mths 6y ago

> If you really want to reduce the unsafe keyword from being seen in most regular code, you create and interface that maps the C++ function and exposes it as a rust function, and you've hidden away your unsafe usage to one spot per function. Isn't that what they did? Through the use of https://github.com/dtolnay/cxx https://github.com/dtolnay/cxx Agreed the article expressed the concern in a rather clumsy manner, but they seem to have a point for their particular use case, and they addressed it appropriately.

kbenson 6y ago
Yeah, in the end, they're taking a somewhat sane approach, it's just rather odd that they identify this as item number 1 that needs addressing. I'm not sure whether it's actually better to abstract all the unsafe away, or force it to shown where it's used. In one respect, they may be right, it might lesson the impact of unsafe and it gets used more freely. On the other, it also means that it's not necessarily immediately obvious when you're crossing boundaries, since the obvious bits and intentionally hidden away. Though I'll freely admit my initial responses were a bit hyperbolic and... testy. :)
- ComputerGuru 6y ago
  I disagree, you can automatically expose any unsafe function with a wrapper _safe function that does nothing more than call the former (possibly also wrapping fundamentally unsafe types in arguments and return values) which makes it appear safe but that doesn’t make it sane. There would need to be domain understanding baked into each wrapper and some contract about what is happening on the other side of the ffi wall for it to qualify as both safe and sane, and I’m not sure their approach meets that high burden.

Impossible 6y ago

Yeah... The unsafe keyword is not unique to Rust either and exist in C# with similar semantics (although slightly different due to gc vs borrow checker memory management). One way to think of it is unsafe blocks effectively let you write C, with pointers and other memory unsafe operations inside of an otherwise safe language. This can be used for performance critical code (in a similar, but higher level, way as inline asm) but is primarily used to interface with unsafe C APIs (OS APIs, graphics APIs, etc) and libraries. Entirely agree that this is a misunderstanding.

emmelaich 6y ago

The Rust definition of 'unsafe' is very far from the everyday meaning. Yeah you can mentally substitute 'rustc_cannot_vouch_for' but why can't Rust use a word closer in meaning to that in the first place? We tend to misuse everyday meanings I think. I reminded of 1. the msdos warning that 'this program has used an illegal instruction and will be shut down' 2. That DNS names with underscore are 'illegal'. This one caused an amusing kerfuffle at one company I worked at. 3. That certain crypto algos are 'broken'

powersnail 6y ago
I'm reminded of "my phone has 64g of memory". It makes sense to a lay person, that memory would mean storage. This is inevitable. We either invent new words, or we use existing words from the natural language. The latter will always lead to confusion at some point, because the domain-specific concept doesn't exist in the rest of the world. To represent such a concept, a word would need to deviate from its everyday usage. I think Rust's "unsafe" is an okay choice; the "vouching" is a feature about memory safety after all.
kbenson 6y ago
> The Rust definition of 'unsafe' is very far from the everyday meaning. "safe" is entirely relative in it's everyday meaning. To one person skydiving is safe, to another it is extremely unsafe. When you're a child your parent will tell you what is safe or not, but what your parent considers safe is based on their personal definition of safety. The rust language will tell you if what you've done is safe based on its very well defined criteria for what that is, and won't let you proceed with something that doesn't match that criteria unless you vouch for it yourself. unsafe makes just as much sense here as any other word, it only seems a wrong fit when you look at it from a context it's not meant to be used in.
- emmelaich 6y ago
  I'd suggest that 'unsafe' is quite far away from the opposite meaning of 'safe' in everyday language.
tracker1 6y ago