This return value needs to be checked more carefully.
If the final path is longer than the buffer, then GetFinalPathNameByHandleW will return the actual length needed, which will convince this if statement that the call succeeded when it didn't, and then we'll process the uninitialized buffer.
How can the final path require a buffer longer than MAX_PATH? Two ways:
Thanks, good catch. Will update with a stack buffer that should fit all practical cases (MAX_PATH+10) and fall back on dynamic allocation if that wasn't big enough.
Rebased, retriggering CI.
Compared to the older version that @amccarth approved, this is a little bit reworked to fit into the POSIX realpath() interface, which means it returns a malloc() allocated buffer, so the end of the function uses a bit of memmove/wcscpy to assemble paths, instead of the slightly simpler version before (when operating on the level of the __canonical function that returns a std::filesystem::path).
This touches the existing code a little bit to just change char into path::value_type, and add the detail:: prefix on the calls to realpath().
The changes to provide realpath on Windows looks right. Since it's relying on a system call, it would be difficult to create tests for the \\?\ and UNC cases. I'm assuming the more mainstream cases will be tested by existing tests. So LGTM.