4 ms·
>`std::env::args` will panic on non-UTF8 content, like a file path. Tell me this is a joke.
by oguz-ismail 2y ago
>`std::env::args` will panic on non-UTF8 content, like a file path.
Tell me this is a joke.
- namibj 2y agoWhat part do you hope/expect to be a joke there?
- Hemospectrum 2y agoThe documentation is quite clear on this point: > The returned iterator will panic during iteration if any argument to the process is not valid Unicode. If this is not desired, use the args_os function instead. std::env::args_os encodes paths as an OsString, which is allowed to contain invalid Unicode. You can then perform your own Unicode validation as needed, instead of the "ASAP" behavior of std::env::args. https://doc.rust-lang.org/std/env/fn.args.html https://doc.rust-lang.org/std/env/fn.args.html
- Analemma_ 2y agoI think this is fine? 99.99% of the time in application-land I want to be working with valid UTF-8 only, and an equal percentage of the time, filenames and CLI args cooperate. And as the sibling comments say, this is all well-documented. Frankly I think the onus should be on operating systems to get with the program and be UTF-8 everywhere (I think UCS-2 on Windows and "bag of bytes" filenames on Linux are braindead), but until that happens we at least have std::env::args_os as an escape hatch.
- Arch-TK 2y agoIf your program, especially if it accepts paths, flakes out over a path with a ISO/IEC 8859-1:1998 filename, it sucks. It's 2024, programs shouldn't be that unreliable. args_os is not an escape hatch, it's a pre-requisite to writing a command line argument parser. Honestly, I think the default args iterator should be deprecated, its functionality can be trivially rebuilt from args_os with the panic becoming more explicit.