why convert to MultiByteToWideChar_1?

[MnabilR]

What's the below code doing ?
Q. What's the purpose of LocalALloc Parameter 2 * v2 + 16?
Q2. Can you tell me about MultiByteToWideChar()? and it's parameter?
Q3. What's the below coding performing?

CHAR *__thiscall ConvertMultiBytetoWideChar(LPCCH lpMultiByteStr)
{
  int v2; // ebx
  WCHAR *v3; // esi


  v2 = lstrlenA_1(lpMultiByteStr);
  v3 = (WCHAR *)LocalAlloc_1(0x40u, 2 * v2 + 16);
  MultiByteToWideChar_1(65001u, 0, lpMultiByteStr, -1, v3, v2);
  v3[v2] = 0;
  return v3;

[Salem]

This looks like the kind of nonsense code spat out by a decompiler.

What are you trying to achieve here?

[aGerman]

Please look up the function references on the Microsoft sites.
Besides of that I think the original code might have been something like that, with some updates that I remarked:

// The return type should be a pointer to WCHAR rather than CHAR!
WCHAR *ConvertMultiBytetoWideChar(LPCCH lpMultiByteStr)
{
  size_t mbLength;
  WCHAR *wBuf;


  // count the CHARs of the incoming string without terminating null char
  // note: counting CHARs means counting code units, not counting code points
  mbCnt = lstrlenA(lpMultiByteStr);


  // Allocate memory of two times as many bytes as mbLength + space for the terminating null.
  // I don't understand why the original code adds 16. Someone might have messed with bytes and bits.
  wBuf = (WCHAR *)LocalAlloc(LMEM_ZEROINIT, sizeof(WCHAR) * mbLength + sizeof(WCHAR));


  // obviously the incoming string is assumed to be UTF-8 encoded (code page ID 65001)
  // the -1 makes the function determine the length again which should have been avoided because we have mbCnt
  // wBuf gets the converted string UTF-16 encoded
  // we have to add +1 to the last argument because this is the number of WCHARs we allocated
  MultiByteToWideChar(CP_UTF8, 0, lpMultiByteStr, -1, wBuf, mbCnt + 1);
  
  // This is triple nonsense because
  // - the return value of MultiByteToWideChar would have indicated the new string length (but we ignore it)
  // - The -1 passed to the MultiByteToWideChar function makes that the terminating null is converted, too
  // - the buffer has been already zero initialized and thus, everything following the last WCHAR will be already 0
  //wBuf[mbCnt] = L'\0';
  
  // return the UTF-16 string.
  // note: the caller is responsible to deallocate the pointer using LocalFree
  return wBuf;
}

[aGerman]

Darn, still typos. That's what I get for writing code directly in the browser

// The return type should be a pointer to WCHAR rather than CHAR!
WCHAR *ConvertMultiBytetoWideChar(LPCCH lpMultiByteStr)
{
  size_t mbCnt;
  WCHAR *wBuf;


  // count the CHARs of the incoming string without terminating null char
  // note: counting CHARs means counting code units, not counting code points
  mbCnt = lstrlenA(lpMultiByteStr);


  // Allocate memory of two times as many bytes as mbCnt + space for the terminating null.
  // I don't understand why the original code adds 16. Someone might have messed with bytes and bits.
  wBuf = (WCHAR *)LocalAlloc(LMEM_ZEROINIT, sizeof(WCHAR) * mbCnt + sizeof(WCHAR));


  // obviously the incoming string is assumed to be UTF-8 encoded (code page ID 65001)
  // the -1 makes the function determine the length again which should have been avoided because we have mbCnt
  // wBuf gets the converted string UTF-16 encoded
  // we have to add +1 to the last argument because this is the number of WCHARs we allocated
  MultiByteToWideChar(CP_UTF8, 0, lpMultiByteStr, -1, wBuf, mbCnt + 1);


  // This is triple nonsense because
  // - the return value of MultiByteToWideChar would have indicated the new string length (but we ignore it)
  // - The -1 passed to the MultiByteToWideChar function makes that the terminating null is converted, too
  // - the buffer has been already zero initialized and thus, everything following the last WCHAR will be already 0
  //wBuf[mbCnt] = L'\0';


  // return the UTF-16 string.
  // note: the caller is responsible to deallocate the pointer using LocalFree
  return wBuf;
}