9 ms·

Hmm, fn before_exec strikes me as a thing that should be gotten rid of entirely in favor of unsafe fn before_exec if the former indeed turned out to actually ha

Hmm, fn before_exec strikes me as a thing that should be gotten rid of entirely in favor of unsafe fn before_exec if the former indeed turned out to actually have the potential to cause undefined behavior. But that'd probably be a breaking change which would require a major version number bump, so deprecation is absolutely the right thing IMO. And it also sets the stage to get rid of it outright come the next major version bump. This is the first such instance of "oops, turns out that wasn't safe after all, that should have been unsafe" that I've heard of in Rust. Is that because this is the first such mistake since the 1.0 milestone (the rest of `unsafe` having been nailed down before 1.0), or have there been other such mistakes that I didn't hear about because I haven't read the notes for all of the prior releases of Rust?

GolDDranks 8y ago
I wonder if they could after some time make it a "harder" deprecation; fail by default, and enabled only with an `#[allow]` annotation.
- tspiteri 8y ago
  That would still break existing code: you have to change it for it to compile. And if you are going to change the code, it makes more sense to change the code to use pre_exec in an unsafe block than to use before_exec with an #[allow] annotation.
pdpi 8y ago
Not sure if there was nothing post-1.0, but this[0] particular mess was just before the 1.0 release and, at the time, caused a fair bit of chaos. 0. http://cglab.ca/~abeinges/blah/everyone-poops/ http://cglab.ca/~abeinges/blah/everyone-poops/
- eridius 8y ago
  I remember that one. It came in just under the deadline and it would have been pretty bad if that got into 1.0. The resolution of this not only had a notable effect on how Rust thought about memory safety (in particular, that leaking memory could not be considered unsafe as it's always possible to construct a leak using safe Rust if you have access to Rc, and as a result `std::mem::forget()` was changed from unsafe to safe), but also informed the way we used RAII going forward, as the fundamental unsafety was due to the use of an RAII value as a token representing external computation and was not itself used in order to perform that computation, which meant leaking the token didn't prevent computation from happening. In all other known cases of RAII, leaking the value is safe because without the value, you can't access the protected resources, but in this case the token represented a thread and the thread of course would continue to run after you leak the token. As a takeaway from this lesson, you can't use tokens to represent external processes, and probably shouldn't use them to represent e.g. hardware that needs to be put back into a known state when the token is dropped unless you have a mutex in there as well (which would cause deadlock if you drop the token and then reuse the resource, rather than sending bad commands that break the hardware). Instead, any time leaking the token would cause unsafety, you need to structure your code to use explicit scopes instead, such that the library can clean up at the end of the scope.
- ComputerGuru 8y ago
  Cached version: http://webcache.googleusercontent.com/search?q=cache:cglab.ca/~abeinges/blah/everyone-poops/&ie=UTF-8&oe=UTF-8&hl=en-us&client=safari http://webcache.googleusercontent.com/search?q=cache:cglab.c...
deleted 8y ago
[deleted]
sanxiyn 8y ago
There has been other instances. One is as_mut_slice, which resulted in 1.15.1 patch release. https://blog.rust-lang.org/2017/02/09/Rust-1.15.1.html https://blog.rust-lang.org/2017/02/09/Rust-1.15.1.html Another is borrow checker bug, which resulted in 1.26.2 patch release. https://blog.rust-lang.org/2018/06/05/Rust-1.26.2.html https://blog.rust-lang.org/2018/06/05/Rust-1.26.2.html
steveklabnik 8y ago
We can’t get rid of it because we have a commitment to not breaking users’ code. There will not be a Rust 2.0. There have been some small soundness holes in the typesystem that we have fixed, resulting in breakage, but since that’s in the language, that’s the only way. A library API is different. There haven’t been many of these though. We did have some point releases which immediately fixed some library errors that were introduced by a release, see 1.15.1. But that was in a new API, and so the chance of breakage was extremely low. This API has been around for years. It is also not used much, given it’s a *NIX specific extension you have to explicitly import. Note that upon using it, you’ll get a warning, so everyone will at least be notified.
- deleted 8y ago
  [deleted]
- cornstalks 8y ago
  > There will not be a Rust 2.0. Isn’t Rust 2018 effectively Rust 2.0 (since it introduced new keywords and requires changes to old code if a user opts in to Rust 2018)? So the function could be made unsafe in Rust 2021 (or whatever it’s called).
  - steveklabnik 8y ago
    No, because it is opt in. All existing code keeps compiling as-is. The standard library cannot change with editions for exactly this reason. It’s compiled with a particular edition, like any other crate, and so can’t work differently in different editions.
    - cornstalks 8y ago
      You’re conflating Cargo, Rust (the language), and std/core libraries, and rustc (the compiler). This is one of the difficult parts of Rust and when people say “there won’t be a Rust 2.0” they don’t clarify which part they’re talking about. Given the tight relationship of all of these parts (despite each one being capable of being individually versioned), it would seem feasible to add a cfg attribute for the Rust edition, and then make the function unsafe if the user had opted in to Rust 2021 (or whatever).

GolDDranks 8y ago

I wonder if they could after some time make it a "harder" deprecation; fail by default, and enabled only with an `#[allow]` annotation.

tspiteri 8y ago
That would still break existing code: you have to change it for it to compile. And if you are going to change the code, it makes more sense to change the code to use pre_exec in an unsafe block than to use before_exec with an #[allow] annotation.

pdpi 8y ago

Not sure if there was nothing post-1.0, but this[0] particular mess was just before the 1.0 release and, at the time, caused a fair bit of chaos. 0. http://cglab.ca/~abeinges/blah/everyone-poops/ http://cglab.ca/~abeinges/blah/everyone-poops/

eridius 8y ago
I remember that one. It came in just under the deadline and it would have been pretty bad if that got into 1.0. The resolution of this not only had a notable effect on how Rust thought about memory safety (in particular, that leaking memory could not be considered unsafe as it's always possible to construct a leak using safe Rust if you have access to Rc, and as a result `std::mem::forget()` was changed from unsafe to safe), but also informed the way we used RAII going forward, as the fundamental unsafety was due to the use of an RAII value as a token representing external computation and was not itself used in order to perform that computation, which meant leaking the token didn't prevent computation from happening. In all other known cases of RAII, leaking the value is safe because without the value, you can't access the protected resources, but in this case the token represented a thread and the thread of course would continue to run after you leak the token. As a takeaway from this lesson, you can't use tokens to represent external processes, and probably shouldn't use them to represent e.g. hardware that needs to be put back into a known state when the token is dropped unless you have a mutex in there as well (which would cause deadlock if you drop the token and then reuse the resource, rather than sending bad commands that break the hardware). Instead, any time leaking the token would cause unsafety, you need to structure your code to use explicit scopes instead, such that the library can clean up at the end of the scope.
ComputerGuru 8y ago
Cached version: http://webcache.googleusercontent.com/search?q=cache:cglab.ca/~abeinges/blah/everyone-poops/&ie=UTF-8&oe=UTF-8&hl=en-us&client=safari http://webcache.googleusercontent.com/search?q=cache:cglab.c...

deleted 8y ago

[deleted]

sanxiyn 8y ago

There has been other instances. One is as_mut_slice, which resulted in 1.15.1 patch release. https://blog.rust-lang.org/2017/02/09/Rust-1.15.1.html https://blog.rust-lang.org/2017/02/09/Rust-1.15.1.html Another is borrow checker bug, which resulted in 1.26.2 patch release. https://blog.rust-lang.org/2018/06/05/Rust-1.26.2.html https://blog.rust-lang.org/2018/06/05/Rust-1.26.2.html

steveklabnik 8y ago

We can’t get rid of it because we have a commitment to not breaking users’ code. There will not be a Rust 2.0. There have been some small soundness holes in the typesystem that we have fixed, resulting in breakage, but since that’s in the language, that’s the only way. A library API is different. There haven’t been many of these though. We did have some point releases which immediately fixed some library errors that were introduced by a release, see 1.15.1. But that was in a new API, and so the chance of breakage was extremely low. This API has been around for years. It is also not used much, given it’s a *NIX specific extension you have to explicitly import. Note that upon using it, you’ll get a warning, so everyone will at least be notified.

deleted 8y ago
[deleted]
cornstalks 8y ago
> There will not be a Rust 2.0. Isn’t Rust 2018 effectively Rust 2.0 (since it introduced new keywords and requires changes to old code if a user opts in to Rust 2018)? So the function could be made unsafe in Rust 2021 (or whatever it’s called).
- steveklabnik 8y ago
  No, because it is opt in. All existing code keeps compiling as-is. The standard library cannot change with editions for exactly this reason. It’s compiled with a particular edition, like any other crate, and so can’t work differently in different editions.
  - cornstalks 8y ago
    You’re conflating Cargo, Rust (the language), and std/core libraries, and rustc (the compiler). This is one of the difficult parts of Rust and when people say “there won’t be a Rust 2.0” they don’t clarify which part they’re talking about. Given the tight relationship of all of these parts (despite each one being capable of being individually versioned), it would seem feasible to add a cfg attribute for the Rust edition, and then make the function unsafe if the user had opted in to Rust 2021 (or whatever).