> The more limited C API (system calls) is also full of race opportunities. The windows file APIs are better, but not a lot better. Sure, there are opportuniti

> The more limited C API (system calls) is also full of race opportunities. The windows file APIs are better, but not a lot better. Sure, there are opportunities for races, but POSIX and the Windows API limit the possible outcomes of concurrent modification, and they also provide tools (fixed file handles, etc.) for well-written programs to prevent TOCTOU bugs. Meanwhile, the std::filesystem API just throws its hands in the air and says that filesystem races are UB, period, making it unusable if the program isn't in complete control of the directory tree it operates on. > Anyway, the problem described in the post (scanning the string twice when converting) is as race prone, or not, as the the filesystem API. I don't see what you mean? The typical scenario here is, you receive some absolute or relative path from an external source, encoded in ASCII or UTF-8 or some other non-UTF-16 encoding, and you want to operate on the file or directory at that path. Your internal path string is never going to change, only the filesystem can change. So there aren't any races from scanning your internal string twice to re-encode it; races can only come from using the re-encoded path in multiple calls to the filesystem API.