Incorrect EOF handling in stdin::lines

[ShaneEverittM]

I tried this code:

use std::io::stdin;

fn main() {
    for line in stdin().lines() {
        let line = line.unwrap();
        println!("{}", line);
    }
}

In windows terminal running Git Bash (also occured in Nushell, though I'm not sure if this is terminal or shell-land), I pressed Ctrl-Z + Enter to send EOF.

I expected to see this happen: The application would gracefully exit the loop

Instead, this happened: I saw this error message:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: InvalidData, message: "Windows stdin in console mode does not support non-UTF-16 input; encountered unpaired surrogate" }', src\main.rs:5:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\eof.exe` (exit code: 101)

Meta

rustc --version --verbose:

rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-pc-windows-msvc
release: 1.69.0
LLVM version: 15.0.7

Backtrace

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: InvalidData, message: "Windows stdin in console mode does not support non-UTF-16 input; encountered unpaired surrogate" }', src\main.rs:5:25
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library\std\src\panicking.rs:579
   1: core::panicking::panic_fmt
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library\core\src\panicking.rs:64
   2: core::result::unwrap_failed
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library\core\src\result.rs:1750
   3: enum2$<core::result::Result<alloc::string::String,std::io::error::Error> >::unwrap<alloc::string::String,std::io::error::Error>
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc\library\core\src\result.rs:1090
   4: eof::main
             at .\src\main.rs:5
   5: core::ops::function::FnOnce::call_once<enum2$<core::result::Result<tuple$<>,std::io::error::Error> > (*)(),tuple$<> >
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc\library\core\src\ops\function.rs:250
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `target\debug\eof.exe` (exit code: 101)

[ChrisDenton]

The underlying regression here is that the way we call WideCharToMultiByte does not accept zero length strings. And we're calling ReadConsole in a way that makes ctrl-z immediately return without reading anything after it. This is important because a zero length read is how we signal to stdlib that an eof has occurred (so ctrl-z handling is pretty indirect).

The fix is simple, if anyone wants to claim this issue. This function needs to check for zero length input and immediately return Ok(0) in that case.

[ShaneEverittM]

Seems like a good first issue, I can take a stab at it.

[ChrisDenton]

That would be great!

[ShaneEverittM]

Where would be a good place to write a test for this?

[ChrisDenton]

Hm, this is a Windows specific issue so it should probably stay close to the affected code. Take a look at how alloc.rs uses alloc/tests.rs for tests and do something similar for stdio.

[ShaneEverittM]

Hm, this is a Windows specific issue so it should probably stay close to the affected code. Take a look at how alloc.rs uses alloc/tests.rs for tests and do something similar for stdio.

That probably won't work since the function is private, right?
Never mind, I see how things are glued together.

[ChrisDenton]

It's a sub module so it should be able to access the private functions of its parent (aka super) module. This is noted in the Rust Reference:

If an item is private, it may be accessed by the current module and its descendants.

[ShaneEverittM]

It's a sub module so it should be able to access the private functions of its parent (aka super) module. This is noted in the Rust Reference:

If an item is private, it may be accessed by the current module and its descendants.

For sure, just misread the directory structure.