diff options
| author | Alex Crichton <alex@alexcrichton.com> | 2024-01-28 11:24:27 -0800 |
|---|---|---|
| committer | Alex Crichton <alex@alexcrichton.com> | 2024-01-28 11:24:27 -0800 |
| commit | b85b2a783b813def53b2a7f0c9b53fed119e2338 (patch) | |
| tree | b062414016cd740f2b933ba6bfb4b4eb4ce15d8e /tests/codegen/src-hash-algorithm/src-hash-algorithm-sha256.rs | |
| parent | 7a34091eed9adcb079035357ffaf2467b0d377fc (diff) | |
| download | rust-b85b2a783b813def53b2a7f0c9b53fed119e2338.tar.gz rust-b85b2a783b813def53b2a7f0c9b53fed119e2338.zip | |
std: Update documentation of seek_write on Windows
Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in #35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states: > If Length and ByteOffset specify a write operation past the current > end-of-file mark, NtWriteFile automatically extends the file and updates > the end-of-file mark; any bytes that are not explicitly written between > such old and new end-of-file marks are defined to be zero. This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.
Diffstat (limited to 'tests/codegen/src-hash-algorithm/src-hash-algorithm-sha256.rs')
0 files changed, 0 insertions, 0 deletions
