|
245 | 245 | //! subsume similar concepts that exist across a wide range of operating systems even if they might
|
246 | 246 | //! use a different name, such as "handle".) An exclusively owned file descriptor is one that no
|
247 | 247 | //! other code is allowed to close, but the owner is allowed to close it any time. A type that owns
|
248 |
| -//! its file descriptor should close it in its `drop` function. Types like [`File`] generally own |
| 248 | +//! its file descriptor should usually close it in its `drop` function. Types like [`File`] generally own |
249 | 249 | //! their file descriptor. Similarly, file descriptors can be *borrowed*. This indicates that the
|
250 | 250 | //! file descriptor will not be closed for the lifetime of the borrow, but it does *not* imply any
|
251 | 251 | //! right to close this file descriptor, since it will likely be owned by someone else.
|
|
257 | 257 | //! other words, a safe function that takes a regular integer, treats it as a file descriptor, and
|
258 | 258 | //! closes it, is *unsound*.
|
259 | 259 | //!
|
| 260 | +//! Not upholding I/O safety and closing a file descriptor without proof of ownership can lead to |
| 261 | +//! misbehavior and even Undefined Behavior in code that relies on ownership of its file |
| 262 | +//! descriptors: the closed file descriptor could be re-allocated to some other library (such as the |
| 263 | +//! allocator or a memory mapping library) and now accessing the file descriptor will interfere in |
| 264 | +//! arbitrarily destructive ways with that other library. |
| 265 | +//! |
260 | 266 | //! Note that this does not talk about performing other operations on the file descriptor, such as
|
261 | 267 | //! reading or writing. For example, on Unix, the [`OwnedFd`] and [`BorrowedFd`] types from the
|
262 | 268 | //! standard library do *not* exclude that there is other code that reads or writes the same
|
|
0 commit comments