std::env::home_dir() is buggy on Windows

[nodakai]

The underlying Win32 API GetUserProfileDirectory() is used in a wrong way:

• https://msdn.microsoft.com/en-us/library/windows/desktop/bb762280%28v=vs.85%29.aspx

It is the in/out parameter lpcchSize rather than the function return value that contains the number of bytes of the returned data. As a result, when neither HOME nor USERPROFILE is set, std::env::home_dir() returns a truncated string "C" when it should return "C:\Users\nodakai", for example.

I'd rather call this bug a result of a lack of idioms for robust interfacing with external C APIs than an instance of careless programming.

How do you like the idea of changing std::sys::c::BOOL to an enum with repr(i32) ? That should be a zero-cost abstraction and std::sys::c will remains a thin wrapper of Win32 API.

[retep998]

If nobody else works on this within 24 hours then I will fix it myself.

[retep998]

To clarify, the value the user passes to lpcchSize is the size of the buffer including space for the null terminator, and the value that is written back to lpcchSize is the size of the data including the null terminator regardless of whether or not it can fit into the buffer provided. If it could only fit part of the data into the buffer it will still write that data with a null terminator to the end of the buffer. The return value is zero if something failed or the buffer was not big enough and non-zero if everything was successful and the buffer was large enough.

[nodakai]

The funny thing here is MSDN doesn't guarantee lpcchSize contains any useful data when the API returns TRUE 😨😨😨

When the input lpcchSize is strictly larger than 1, though, it seems to hold that _tcslen(lpProfileDir) + 1 == *lpcchSize

[retep998]

Well I got that information through local testing and Windows has fairly solid backwards compatibility guarantees, so we can probably just assume that is the intended usage until proven otherwise.

[nodakai]

Fixed by #31557