Tracking Issue for RFC 3128: I/O Safety

[joshtriplett]

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.

[sunfishcode]

I've now posted an initial PR implementing the proposal in the RFC: #87329