Description
Feature gate: #![feature(io_safety)]
This is a tracking issue for RFC 3128: I/O Safety.
Raw OS handles such as RawFd
and RawHandle
have hazards similar to raw pointers; they may be bogus or may dangle, leading to broken encapsulation boundaries and code whose behavior is impossible to bound in general.
Introduce a concept of I/O safety, and introduce a new set of types and traits, led by OwnedFd
and BorrowedFd
, to support it.
Public API
The public API on UNIX platforms consists of the types OwnedFd
and BorrowedFd
, the trait AsFd
, and implementations of AsFd
, Into<OwnedFd>
, and From<OwnedFd>
for various types (such as files and sockets).
The public API on Windows platforms consists of two sets of parallel types and traits and impls for OwnedHandle
, OwnedSocket
, BorrowedHandle
, BorrowedSocket
, etc.
Steps / History
- Implementation (based on @sunfishcode's existing work outside of std)
- Final comment period (FCP)
- Because these include a new stable layout guarantee (Add rustc_nonnull_optimization_guaranteed to Owned/Borrowed Fd/Socket #96947), this should include T-lang (https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rustc_nonnull_optimization_guaranteed.20oversight.3F)
- Stabilization PR
Unresolved Questions
- This RFC doesn't define a formal model for raw handle ownership and lifetimes. The rules for raw handles in this RFC are vague about their identity. What does it mean for a resource lifetime to be associated with a handle if the handle is just an integer type? Do all integer types with the same value share that association?
- The Rust reference defines undefined behavior for memory in terms of LLVM's pointer aliasing rules; I/O could conceivably need a similar concept of handle aliasing rules. This doesn't seem necessary for present practical needs, but it could be explored in the future.