Fix a relatively nasty bug with fs::getPathFromOpenFD() on Windows. The GetFinalPathNameByHandle API does not behave as documented; if given a buffer that has enough space for the path but not the null terminator, the call will return the number of characters required *without* the null terminator (despite being documented otherwise) and it will not set GetLastError(). The result was that this function would return a bogus path and no error. Instead, ensure there is sufficient space for a null terminator (we already strip it off manually for compatibility with older versions of Windows).
llvm-svn: 273195
diff --git a/llvm/lib/Support/Windows/Path.inc b/llvm/lib/Support/Windows/Path.inc
index 5f588d7..8e5931c 100644
--- a/llvm/lib/Support/Windows/Path.inc
+++ b/llvm/lib/Support/Windows/Path.inc
@@ -821,11 +821,19 @@
DWORD CharCount;
do {
+ // FIXME: We should be using the W version of this API and converting the
+ // resulting path to UTF-8 to handle non-ASCII file paths.
CharCount = ::GetFinalPathNameByHandleA(FileHandle, ResultPath.begin(),
- ResultPath.capacity(), FILE_NAME_NORMALIZED);
- if (CharCount <= ResultPath.capacity())
+ ResultPath.capacity(),
+ FILE_NAME_NORMALIZED);
+ if (CharCount < ResultPath.capacity())
break;
- ResultPath.reserve(CharCount);
+
+ // Reserve sufficient space for the path as well as the null character. Even
+ // though the API does not document that it is required, if we reserve just
+ // CharCount space, the function call will not store the resulting path and
+ // still report success.
+ ResultPath.reserve(CharCount + 1);
} while (true);
if (CharCount == 0)
@@ -833,7 +841,8 @@
ResultPath.set_size(CharCount);
- // On earlier Windows releases, the character count includes the terminating null.
+ // On earlier Windows releases, the character count includes the terminating
+ // null.
if (ResultPath.back() == '\0')
ResultPath.pop_back();