Windows 7: std::io::last_os_error is set after printing to stdout

[nicokoch]

This happens on Windows 7, cannot test on newer Windows.
Basically, something wrong happens with file handles when using the println! macro, not sure what exactly.

Minimal repro:

use std::io;
fn main() {
    println!("{:?}", io::Error::last_os_error());
    println!("{:?}", io::Error::last_os_error());
}

Actual output:

Os { code: 0, kind: Other, message: "Der Vorgang wurde erfolgreich beendet." }
Os { code: 6, kind: Other, message: "Das Handle ist ungültig." }

Expected output:

Os { code: 0, kind: Other, message: "Der Vorgang wurde erfolgreich beendet." }
Os { code: 0, kind: Other, message: "Der Vorgang wurde erfolgreich beendet." }

Sorry for German localization in the error messages.

I noticed this because of some obscure behaviour in the windows API (a function returned != 0, but LastError wasn't set accordingly).

cc @retep998
cc retep998/winapi-rs#658

[nicokoch]

Additional info: I am using stable rust 1.28

[hellow554]

Works for me on Windows 10:

• 1.27.2
• 1.28
• beta
• nightly

Can't test Windows 7 :( sorry

[hellow554]

Does it occur more than once? (e.g. can you reproduce it?)

[nicokoch]

Yes, this happens every time I execute the program

[kennytm]

("Das Handle ist ungültig" means "The handle is invalid" in English)

[sfackler]

Seems like it could be this call: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/stdio.rs#L43-L46

[retep998]

Windows system functions generally guarantee that they will set the last error when they fail, but offer no guarantees as to the state of the last error when they succeed (some may clear the error, some may leave it alone, some may change it).

The only action that Rust could take here is for any libstd function that calls system functions to clear the last error when it returns success.

[nicokoch]

@sfackler I'm using git bashon windows 7 (which is just the mingw terminal if I'm not mistaken).
Probably that resolves to Pipe in the call you mentioned.

Maybe we should SetLastError(0) in that branch?

I understand this is not really a bug (if the function errors, we have a pipe, otherwise a terminal), but perhaps we can reduce the confusion if we reset the OS error in the former case.

[retep998]

Personally I'd rather that Rust offer no guarantees about the result of Error::last_os_error() when called after any libstd function that calls some system function. It should only be used directly after calling a system function yourself and only when that function is documented to have set the last error.

There is a case to be made here about documenting this though.

[steveklabnik]

Triage:

There is a case to be made here about documenting this though.

I agree, though we should get @rust-lang/libs signoff before re-categorizing this bug.

[Zymlex]

Same problem.

As I see line break affects.

Normal:

let mut stdout = stdout();
stdout.write_fmt(format_args!("{}", unsafe { winapi::um::errhandlingapi::GetLastError() }));
stdout.write_fmt(format_args!("{}", unsafe { winapi::um::errhandlingapi::GetLastError() }));

Normal:

print!("{}", Error::last_os_error());
print!("{}", Error::last_os_error());

Bug:

let mut stdout = stdout();
stdout.write_fmt(format_args!("{}\n", unsafe { winapi::um::errhandlingapi::GetLastError() }));
stdout.write_fmt(format_args!("{}", unsafe { winapi::um::errhandlingapi::GetLastError() }));

Bug:

println!("{}", Error::last_os_error());
println!("{}", Error::last_os_error());

Windows 10
1.51.0-nightly
1.49.0-stable