stdin.getEndPos() throws an unexpected error when no input is pipped in.

[MassKlaus]

Zig Version

0.12.0

Steps to Reproduce and Observed Output

Reproduction steps:

have this code anywhere in the code:

    const stdout = std.io.getStdOut().writer();
    var writer = std.io.bufferedWriter(stdout);

    const stdin = std.io.getStdIn();
    const end = stdin.getEndPos() catch 0;

throws

steps [4/7] install... error.Unexpected: GetLastError(1): Incorrect function.

C:\Programs\Zig\lib\std\os\windows.zig:1412:49: 0x3f4957 in GetFileSizeEx (menu.exe.obj)
            else => |err| return unexpectedError(err),
                                                ^
C:\Programs\Zig\lib\std\fs\File.zig:314:37: 0x3f1b11 in getEndPos (menu.exe.obj)
        return windows.GetFileSizeEx(self.handle);
                                    ^
C:\Users\Massine\Coding\Home\zig\menu\src\main.zig:19:32: 0x3f16f0 in main (menu.exe.obj)
    const end = stdin.getEndPos() catch 0;
                               ^
C:\Programs\Zig\lib\std\start.zig:350:53: 0x3f221c in WinStartup (menu.exe.obj)
    std.os.windows.ntdll.RtlExitUserProcess(callMain());
                                                    ^
???:?:?: 0x7ffb5b937343 in ??? (KERNEL32.DLL)
???:?:?: 0x7ffb5c6e26b0 in ??? (ntdll.dll)

Error code 1 meaning ERROR_INVALID_FUNCTION as the windows documentation says

Expected Output

No error

[squeek502]

Some info from some quick testing:

• Calling GetFileType on stdin when there's no input returns 2 which is FILE_TYPE_CHAR
• Calling GetFileSizeEx (which is what getEndPos does on Windows) on a FILE_TYPE_CHAR handle leads to Incorrect function. and error.Unexpected, as shown in the OP
• Calling NtQueryInformationFile (which is what File.stat does) on a FILE_TYPE_CHAR handle leads to NTSTATUS C0000010 which is STATUS_INVALID_DEVICE_REQUEST (currently leads to error.Unexpected)

One possibility here would be to call NtQueryVolumeInformationFile in getEndPos/stat/etc to determine if the handle is valid for the operation. Another option would be to catch and handle/return the relevant errors in getEndPos/stat/etc.

[MassKlaus]

I would say expanding the error set would be the best way to handle this. Since similar errors could rise in different location throughout the winAPI and having the error enums be able to encapsulate the error is important.

Although, I'm quite new to most of the language so I might be off the mark.