-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std: Make FromRawFd::from_raw_fd an unsafe method #24251
Conversation
r? @aturon |
cc @Stebalien |
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
Thanks. lgtm (except I think you meant to close rust-lang/rfcs#1043). |
As pointed out in [RFC issue 1043][rfc] it is quite useful to have the standard I/O types to provide the contract that they are the sole owner of the underlying object they represent. This guarantee enables writing safe interfaces like the `MemoryMap` API sketched out in that issue. [rfc]: rust-lang/rfcs#1043 As constructing objects from these raw handles may end up violating these ownership gurantees, the functions for construction are now marked unsafe. [breaking-change] Closes rust-lang/rfcs#1043
Oops I did indeed! |
d71264b
to
2705051
Compare
@bors: r+ |
📌 Commit 2705051 has been approved by |
As pointed out in [RFC issue 1043][rfc] it is quite useful to have the standard I/O types to provide the contract that they are the sole owner of the underlying object they represent. This guarantee enables writing safe interfaces like the `MemoryMap` API sketched out in that issue. [rfc]: rust-lang/rfcs#1043 As constructing objects from these raw handles may end up violating these ownership gurantees, the functions for construction are now marked unsafe. [breaking-change] Closes rust-lang/rfcs#1043
⛄ The build was interrupted to prioritize another pull request. |
⌛ Testing commit 2705051 with merge ef6f489... |
💔 Test failed - auto-win-32-nopt-t |
@bors: retry |
⌛ Testing commit 2705051 with merge 3f8fed6... |
💔 Test failed - auto-win-32-nopt-t |
@bors: retry On Mon, Apr 13, 2015 at 5:01 PM, bors notifications@github.com wrote:
|
As pointed out in [RFC issue 1043][rfc] it is quite useful to have the standard I/O types to provide the contract that they are the sole owner of the underlying object they represent. This guarantee enables writing safe interfaces like the `MemoryMap` API sketched out in that issue. [rfc]: rust-lang/rfcs#1043 As constructing objects from these raw handles may end up violating these ownership gurantees, the functions for construction are now marked unsafe. [breaking-change] Closes rust-lang/rfcs#1043
I'm a bit late but this issue was already pointed out by #19169 some months ago. Why not use the file descriptor's owner lifetime for the return object to guarantee a safe file descriptor use? Replacing It sounds reasonable to use a mutable |
|
I though This way, the
The
Yes, the object's inner file descriptor should go from |
Well, I think it should be enough to put a |
Lifetime fix from |
Lifetimes aren't the issue. Say I want to create a |
Yes, that's the price for a safe
I don't think it's currently possible to create a |
The type
Which means the new You're missing the entire point of fn open_custom_file() -> File {
unsafe {
let my_fd = libc::open(...);
File::from_raw_fd(my_fd)
}
}
fn my_c_api_wrapper() -> File {
unsafe {
let fd = my_c_api::something_that_returns_an_fd();
File::from_raw_fd(fd)
}
} In other words, it's designed to be paired with unsafe code. |
It depend of the
Not necessarily, the
I understand quite well the current status of
For now, yes, but I think we could manage to remove the need for the code to be unsafe . Your example is legitimate, but do not automatically handle the file descriptor closing, which is why it's unsafe. Instead, it rely on the A more generic way to handle file descriptor is to wrap it with a dedicated object like My proposal would allow to continue using file descriptors for FFI, but moreover, to safely temporally pass the file descriptor to another object and get it back without closing it (but remain safe), if needed, which is not possible right now because the cc @carllerche, @reem |
No.
let mm: MemoryMap<MyStructs> = MemoryMap::with_capacity(20) // Create a file and allocate 20 MyStructs worth of space.
// Use mm...
{
let file = File::from_raw_fd(mm)
// write to the file
}
// Use mm...
// SEGFAULT because writing to mm is equivalent to transmuting `[u8]` to `MyStruct` It's perfectly reasonable to have |
I known, I quoted it. It's a contract, it's not enforced by the compiler. This example does not demonstrate the type safety problem because the The issue in this example could be to force the |
Another way to make it simple (without explicit lifetime), is to use a minimal (inner) object handling the file descriptor lifetime (e.g. |
Neither is "don't close the file descriptor" (the contract you'd need to make your proposal work).
Sorry, I meant |
Anyways, this discussion should probably go in an RFC. |
I think in general there's a bit of a disconnect about where you want the standard library to go with these sorts of primitives and the vision that we've set for for the I/O modules currently. The current design is intentionally conservative in these respects, providing the bare bones primitives necessary to accomplish these sorts of tasks instead of trying to provide a comprehensive solution to interoperating with system primitives. We expected nicer utilities for dealing with these kinds of applications to grow naturally in the crates.io ecosystem, but not in the standard library. If you'd like to pursue a much more featureful suite of primitives in the standard library I would recommend writing an RFC. |
As pointed out in RFC issue 1043 it is quite useful to have the standard
I/O types to provide the contract that they are the sole owner of the underlying
object they represent. This guarantee enables writing safe interfaces like the
MemoryMap
API sketched out in that issue.As constructing objects from these raw handles may end up violating these
ownership gurantees, the functions for construction are now marked unsafe.
[breaking-change]
Closes rust-lang/rfcs#1043