GetFinalPathNameByHandleW should be audited

[lilyball]

The call to GetFinalPathNameByHandleW() in src/libnative/io/file.rs needs to be audited. I am not a Windows developer, but my interpretation of the documentation indicates that the buffer length provided to that function should be 1 less than the actual buffer size. The reasoning is that the documentation states:

cchFilePath [in]
The size of lpszFilePath, in TCHARs. This value does not include a NULL termination character.

yet the function itself will NULL-terminate the output it writes. To me this says that it will write one more TCHAR to the buffer than is indicated by cchFilePath.

This should be verified by someone who is actually familiar with Windows APIs.

[huonw]

It seems relatively likely that there would be other functions like this too.

[lilyball]

Sure, I was looking at this in conjunction with fill_utf16_buf_and_decode(). There are only 3 Windows functions called with fill_utf16_buf_and_decode(), and the other two are documented as taking a size that includes the NULL. But it's entirely possible there are other Windows API functions used in other situations that have similar concerns.