Failure to spawn on Windows if stdio handles are null #31167
Labels
O-windows
Operating system: Windows
Comments
|
cc @emoon |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jan 26, 2016
On all platforms, reading from stdin where the actual stdin isn't present should return 0 bytes as having been read rather than the entire buffer. On Windows, handle the case where we're inheriting stdio handles but one of them isn't present. Currently the behavior is to fail returning an I/O error but instead this commit corrects it to detecting this situation and propagating the non-set handle. Closes rust-lang#31167
Manishearth
added a commit
to Manishearth/rust
that referenced
this issue
Jan 26, 2016
On all platforms, reading from stdin where the actual stdin isn't present should return 0 bytes as having been read rather than the entire buffer. On Windows, handle the case where we're inheriting stdio handles but one of them isn't present. Currently the behavior is to fail returning an I/O error but instead this commit corrects it to detecting this situation and propagating the non-set handle. Closes rust-lang#31167
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As reported here, if one of the stdio handles for a Windows process is unset (e.g. isn't present) then you won't actually be able to spawn a process by default. All handles are set, by default, to "inherit", but this currently means duplicate the existing handle, which in turn means that if the stdio handle isn't present this operation will fail.
Rust currently defends against this by always opening up handles even if
Stdio::null()is specified (just pointing them to a blank stream), but Rust should also defend against this situation when it was spawned from elsewhere.The text was updated successfully, but these errors were encountered: