rust/library/std/src/os/windows, branch 1.77.2

Document Windows argument splitting

2024-04-08T23:09:23+00:00

std: Update documentation of seek_write on Windows

2024-01-28T19:24:27+00:00

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.

Fix tracking issue of Windows ExitCodeExt

2023-11-23T19:16:10+00:00

unnecessary_mut_passed

2023-11-22T13:00:28+00:00

This is where our Windows API bindings previously (and incorrectly) used `*mut` instead of `*const` pointers. Now that the bindings have been corrected, the mutable references (which auto-convert to `*mut`) are unnecessary and we can use shared references.

useless_conversion

2023-11-22T13:00:28+00:00

Substitute version placeholders

2023-11-16T00:40:51+00:00

Stabilize `file_set_times`

2023-10-31T06:34:02+00:00

Approved via FCP in https://github.com/rust-lang/rust/issues/98245 .

Bump version placeholders

2023-10-04T00:26:36+00:00

Auto merge of #114882 - ChrisDenton:riddle-me, r=dtolnay

2023-09-28T13:35:36+00:00

Update windows ffi bindings Bump `windows-bindgen` to version 0.51.1. This brings with it some changes to the generated FFI bindings, but little that affects the code. One change that does have more of an impact is `SOCKET` being `usize` instead of either `u64` or `u32` (as is used in std's public `SOCKET` type). However, it's now easy enough to abstract over that difference. Finally I added a few new bindings that are likely to be used in pending PRs, mostly to make sure they're ok with the new metadata. r? libs

Auto merge of #98704 - vthib:impl-from-raw-for-childstd-structs, r=dtolnay

2023-09-28T09:59:03+00:00

Implement From for ChildStdin/out/err object ## Summary Comments in `library/std/src/process.rs` ( https://github.com/rust-lang/rust/commit/ab08639e5950f5c8a42a2870c9636181308c3686 ) indicates that `ChildStdin`, `ChildStdout`, `ChildStderr` implements some traits that are not actually implemented: `FromRawFd`, `FromRawHandle`, and the `From/From` from the io_safety feature. In this PR I implement `FromRawHandle` and `FromRawFd` for those 3 objects. ## Usecase I have a usecase where those implementations are basically needed. I want to customize in the `Command::spawn` API how the pipes for the parent/child communications are created (mainly to strengthen the security attributes on them). I can properly setup the pipes, and the "child" handles can be provided to `Child::spawn` easily using `Stdio::from_raw_handle`. However, there is no way to generate the `ChildStd*` objects from the raw handle of the created name pipe, which would be very useful to still expose the same API than in other OS (basically a `spawn(...) -> (Child, ChildStdin, ChildStdout, ChildSterr)`, where on windows this is customized), and to for example use `tokio::ChildStdin::from_std` afterwards. ## Questions * Are those impls OK to add? I have searched to see if those impls were missing on purpose, or if it was just never implemented because never needed. I haven't found any indication on why they couldn't be added, although the user clearly has to be very careful that the handle provided makes sense (i think, mainly that it is in overlapped mode for windows). * If this change is ok, adding the impls for the io_safety feature would probably be best, or should it be done in another PR? * I just copy-pasted the `#[stable(...)]` attributes, but the `since` value has to be updated, I'm not sure to which value.