Successive calls to RegGetValue return two different sizes for the same string

Question

In some code I use the Win32 RegGetValue() API to read a string from the registry.

I call the aforementioned API twice:

1. The purpose of the first call is to get the proper size to allocate a destination buffer for the string.

2. The second call reads the string from the registry into that buffer.

What is odd is that I found that RegGetValue() returns different size values between the two calls.

In particular, the size value returned in the second call is two bytes (equivalent to one wchar_t) less than the first call.

It's worth noting that the size value compatible with the actual string length is the value returned by the second call (this corresponds to the actual string length, including the terminating NUL).
But I don't understand why the first call returns a size two bytes (one wchar_t) bigger than that.

A screenshot of program output and Win32 C++ compilable repro code are attached.

---

Repro Source Code

#include <windows.h>
#include <iostream>
#include <string>
#include <vector>
using namespace std;


void PrintSize(const char* const message, const DWORD sizeBytes)
{
    cout << message << ": " << sizeBytes << " bytes (" 
         << (sizeBytes/sizeof(wchar_t)) << " wchar_t's)\n";
}


int main()
{
    const HKEY key = HKEY_LOCAL_MACHINE;
    const wchar_t* const subKey = L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion";
    const wchar_t* const valueName = L"CommonFilesDir";

    //
    // Get string size
    //
    DWORD keyType = 0;
    DWORD dataSize = 0;
    const DWORD flags = RRF_RT_REG_SZ;
    LONG result = ::RegGetValue(
        key, 
        subKey,
        valueName, 
        flags, 
        &keyType, 
        nullptr, 
        &dataSize);
    if (result != ERROR_SUCCESS)
    {
        cout << "Error: " << result << '\n';
        return 1;
    }
    PrintSize("1st call size", dataSize);
    const DWORD dataSize1 = dataSize; // store for later use


    //
    // Allocate buffer and read string into it
    //
    vector<wchar_t> buffer(dataSize / sizeof(wchar_t));
    result = ::RegGetValue(
        key, 
        subKey,
        valueName, 
        flags, 
        nullptr, 
        &buffer[0], 
        &dataSize);
    if (result != ERROR_SUCCESS)
    {
        cout << "Error: " << result << '\n';
        return 1;
    }
    PrintSize("2nd call size", dataSize);

    const wstring text(buffer.data());
    cout << "Read string:\n";
    wcout << text << '\n';
    wcout << wstring(dataSize/sizeof(wchar_t), L'*')  << "  <-- 2nd call size\n";
    wcout << wstring(dataSize1/sizeof(wchar_t), L'-') << "  <-- 1st call size\n"; 
}

---

Operating System: Windows 7 64-bit with SP1

---

EDIT

Some confusion seems to be arisen by the particular registry key I happened to read in the sample repro code.
So, let me clarify that I read that key from the registry just as a test. This is not production code, and I'm not interested in that particular key. Feel free to add a simple test key to the registry with some test string value.
Sorry for the confusion.

Answer 1

This blog post (published on February 14th, 2024) clarifies the issue:

The Old New Thing - Functions that return the size of a required buffer generally return upper bounds, not tight bounds

There are a number of functions in Windows that are part of a three-phase operation:

1. Request the size of a buffer needed to receive some data.
2. Allocate a buffer of that size.
3. Call the function again with that buffer.

When you ask for the required size of a buffer, it is not uncommon for the function to return a value that larger than the actual value you get from step 3, when you ask for the data to be placed in the buffer.

[…] Given that the caller has to be prepared for the size to change anyway, the “how big of a buffer do I need” call can return an over-estimate of the required size, since that will allow the second call for the data to succeed (assuming the data hasn’t changed). And giving an over-estimate is often much easier than giving an exact value.

I think the official MSDN documentation should be updated with that information.