Fix getting/setting huge env vars on windows

[alexcrichton]

On windows, the GetEnvironmentVariable function will return the necessary buffer
size if the buffer provided was too small. This case previously fell through the
checks inside of fill_utf16_buf_and_decode, tripping an assertion in the slice
method.

This adds an extra case for when the return value is >= the buffer size, in
which case we assume the return value as the new buffer size and try again.

Closes #12376

[flaper87]

LGTM

[lilyball]

One of the Windows functions called using fill_utf16_buf_and_decode() (GetFinalPathNameByHandleW) is documented as taking a buffer size that does not include the NULL terminator. This has me worried. It sounds like if the function wants to write precisely the same number of characters as is passed, it will attempt to write a NULL byte past the end of the buffer. I would love to be wrong about this, but it sounds to me like someone needs to audit that call.

[alexcrichton]

If the function fails because lpszFilePath is too small to hold the string plus the terminating null character, the return value is the required buffer size, in TCHARs. This value includes the size of the terminating null character.

It sounds like so long as we use the return value as the next length, we'll have the right sized buffer.

[lilyball]

@alexcrichton Yes, my concern does not impact this particular PR. I was looking at it to find out the reasoning for the k == n branch (which is the case for GetFinalPathNameByHandleW). Someone who's actually familiar with the Windows APIs should take a look and decide if GetFinalPathNameByHandleW really is expecting the length to be provided as 1 smaller than the actual size of the buffer, which is my interpretation of the documentation. Because if so, then the call to GetFinalPathNameByHandleW needs to subtract one from the length, which it is not currently doing, in order to ensure the buffer is not overrun.

[huonw]

(I've removed my r+, just in case.)

[lilyball]

I have filed an issue for my concern as #12406. Given that, since I think this patch is fine as-is, @huonw you should probably restore your r+.

[alexcrichton]

@kballard, thanks!