zig fmt rejects paths using forward slash instead of backslash on Windows

[ErikMcClure]

For some reason, attempting to use zig fmt will fail on windows if the path uses / instead of \:

PS D:\test> zig version
0.4.0+6d73e5de
PS D:\test> zig fmt ./src/schema.zig      
unable to open './src/schema.zig': error.BadPathName
PS D:\test> zig fmt .\src\schema.zig
PS D:\test>

No other part of zig cares if you use / or \ on windows (but linux will only accept /), so this seems like an oversight.

[FireFox317]

Well, in the standard library of Zig it is mentioned that / is disallowed and since zig fmt is self-hosted and uses the std library it is not allowed. The following is said in the std/os/windows.zig:

// > File I/O functions in the Windows API convert "/" to "" as part of
// > converting the name to an NT-style name, except when using the "\?"
// > prefix as detailed in the following sections.
// from https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation
// Because we want the larger maximum path length for absolute paths, we
// disallow forward slashes in zig std lib file functions on Windows.

Maybe we should also disallow / in the rest of the compiler.

[ErikMcClure]

I would argue that this goes against how most tools in windows operate, which is accepting both / and \ in the file path arguments. However, as long as the behavior Zig chooses is consistent, it doesn't really matter.

[andrewrk]

I don't remember writing that comment, I'm going to audit this code

[emekoi]

i'm pretty sure this is because zig isn't escaping the \ in the path name.

[BarabasGitHub]

// Because we want the larger maximum path length for absolute paths, we
// disallow forward slashes in zig std lib file functions on Windows.

Ehm... just convert \ to /? It already has to copy and convert to utf16 anyway.

It has to be handled somewhere at least.