mirrors/zig
1
0
Fork 0
mirror of https://codeberg.org/ziglang/zig.git synced 2025-12-06 05:44:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
zig/test/standalone/windows_argv/README.md
Ryan Liptak f4c4c04f1c ArgIteratorWindows: Match post-2008 C runtime rather than CommandLineToArgvW 
On Windows, the command line arguments of a program are a single WTF-16 encoded string and it's up to the program to split it into an array of strings. In C/C++, the entry point of the C runtime takes care of splitting the command line and passing argc/argv to the main function.

https://github.com/ziglang/zig/pull/18309 updated ArgIteratorWindows to match the behavior of CommandLineToArgvW, but it turns out that CommandLineToArgvW's behavior does not match the behavior of the C runtime post-2008. In 2008, the C runtime argv splitting changed how it handles consecutive double quotes within a quoted argument (it's now considered an escaped quote, e.g. `"foo""bar"` post-2008 would get parsed into `foo"bar`), and the rules around argv[0] were also changed.

This commit makes ArgIteratorWindows match the behavior of the post-2008 C runtime, and adds a standalone test that verifies the behavior matches both the MSVC and MinGW argv splitting exactly in all cases (it checks that randomly generated command line strings get split the same way).

The motivation here is roughly the same as when the same change was made in Rust (https://github.com/rust-lang/rust/pull/87580), that is (paraphrased):

- Consistent behavior between Zig and modern C/C++ programs
- Allows users to escape double quotes in a way that can be more straightforward

Additionally, the suggested mitigation for BatBadBut (https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/) relies on the post-2008 argv splitting behavior for roundtripping of the arguments given to `cmd.exe`. Note: it's not necessary for the suggested mitigation to work, but it is necessary for the suggested escaping to be parsed back into the intended argv by ArgIteratorWindows after being run through a `.bat` file.
2024-04-15 02:09:48 -07:00

2 KiB
Raw Permalink Blame History

Tests that Zig's std.process.ArgIteratorWindows is compatible with both the MSVC and MinGW C runtimes' argv splitting algorithms.

The method of testing is:

  • Compile a C file with wmain as its entry point
  • The C wmain calls a Zig-implemented verify function that takes the argv from wmain and compares it to the argv gotten from std.proccess.argsAlloc (which takes kernel32.GetCommandLineW() and splits it)
  • The compiled C program is spawned continuously as a child process by the implementation in fuzz.zig with randomly generated command lines
    • On Windows, the 'application name' and the 'command line' are disjoint concepts. That is, you can spawn foo.exe but set the command line to bar.exe, and CreateProcessW will spawn foo.exe but argv[0] will be bar.exe. This quirk allows us to test arbitrary argv[0] values as well which otherwise wouldn't be possible.

Note: This is intentionally testing against the C runtime argv splitting and not CommandLineToArgvW, since the C runtime argv splitting was updated in 2008 but CommandLineToArgvW still uses the pre-2008 algorithm (which differs in both argv[0] rules and ""; see here for details)

In addition to being run during zig build test-standalone, this test can be run on its own via zig build test from within this directory.

When run on its own:

  • -Diterations=<num> can be used to set the max fuzzing iterations, and -Diterations=0 can be used to fuzz indefinitely
  • -Dseed=<num> can be used to set the PRNG seed for fuzz testing. If not provided, then the seed is chosen at random during build.zig compilation.

On failure, the number of iterations and the seed can be seen in the failing command, e.g. in path\to\fuzz.exe path\to\verify-msvc.exe 100 2780392459403250529, the iterations is 100 and the seed is 2780392459403250529.