Fix ctrl-c causing reads of stdin to return empty on Windows.

[arlosi]

Pressing ctrl+c (or ctrl+break) on Windows caused a blocking read of stdin to unblock and return empty, unlike other platforms which continue to block.

On ctrl-c, ReadConsoleW will return success, but also set LastError to ERROR_OPERATION_ABORTED.

This change detects this case, and re-tries the call to ReadConsoleW.

Fixes #89177. See issue for further details.

Tested on Windows 7 and Windows 10 with both MSVC and GNU toolchains

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[fee1-dead]

Can you add an ui test for this? (see this for how to add one yourself)

Ideally we would want to make sure this behavior is consistent across all the platforms that we support.

It would probably look like this file, although I am not sure how to programmatically send Ctrl-C to a process... (and there might be platforms that do not care about Ctrl-Cs)

[Mark-Simulacrum]

I think a test will be difficult -- maybe a run-make test with a kill command sending the appropriate signal? Seems complicated and may not be warranted.

I'm going to r? @dtolnay since this seems like it'll require a T-libs-api (or so) FCP, as a breaking change.

[arlosi]

Yes, adding a test is rather difficult. Windows doesn't really have a kill like syscall that sends SIGINT.

The closest thing seems to be setting up separate process group for a subprocess, then calling the Windows GenerateConsoleCtrlEvent API on the group. However, I wasn't able to reproduce the current behavior using this approach -- and even if we could make it work, the test would be very Windows-specific.

[dtolnay]

This PR closes an inconsistency between how the standard library implements reading from stdin on Windows vs other platforms. #89177 (comment) is the clearest example of the discrepancy: ctrl+C during a read would previously cause the read to return on Windows, but not other platforms, while the ctrl+C handler runs.

I don't believe we want to keep this as a platform-specific inconsistency. As for which behavior to go with, I would biasedly say the non-Windows behavior seems better to me, which this PR makes the Windows implementation consistent with.

@rust-lang/libs-api
@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[BurntSushi]

This seems okay to me from a consistency perspective, but I wonder how other ecosystems handle this? Has anyone done a survey?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[arlosi]

I tested a few different languages on Windows 10 with the program:

• Set signal handler to catch ctrl-c and print a message
• Read a line of text

The behavior of the readline call after pressing ctrl-c are a mixture on Windows:

Language	readline keeps blocking	readline raises error
Rust (now)	❌	❌
Rust (this PR)	✔️	❌
Go	❌	✔️ (EOF)
Node (JavaScript)	✔️	❌
Ruby	✔️	❌
.NET Core	❌	❌
Python	❌	✔️ (Exception)

All test programs have the same behavior on Linux (keep blocking, no error). For consistency, converging on "keep blocking, no error" (as this PR does) makes the most sense to me.

The alternative of returning an error in Rust can cause problems if no signal handler is set up, since Windows kills the thread after a few milliseconds, sometimes causing a half-printed error message.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[joshtriplett]

@bors r+

[bors]

📌 Commit 273e522 has been approved by joshtriplett