`STRSAFE_NO_TRUNCATION`和`STRSAFE_NULL_ON_FAILURE`值的区别是什么？

Question

The StringCchCopyEx function has values STRSAFE_NULL_ON_FAILURE and STRSAFE_NO_TRUNCATION for own flags. I am reading MSDN and I don't see their difference:

STRSAFE_NULL_ON_FAILURE

If the function fails, pszDest is set to an empty string ( TEXT("") ). In the case of a STRSAFE_E_INSUFFICIENT_BUFFER failure, any truncated string is overwritten.

STRSAFE_NO_TRUNCATION

As in the case of STRSAFE_NULL_ON_FAILURE , if the function fails, pszDest is set to an empty string ( TEXT("") ). In the case of a STRSAFE_E_INSUFFICIENT_BUFFER failure, any truncated string is overwritten.

Also I don't see the difference in my code results:

LPCTSTR pSrc = L"ASDFGHJK";

size_t charsCount = 5;
size_t buffer_size = charsCount * sizeof(TCHAR);
TCHAR *buffer = (TCHAR *) malloc(buffer_size);
ZeroMemory(buffer, buffer_size);    

// Now I generate the STRSAFE_E_INSUFFICIENT_BUFFER result...

LPTSTR pDestEnd = NULL;
size_t remaind = 0;

// The MEMORY content after the StringCchCopyEx executing:
// 00 00 53 00 44 00 46 00 00 00 fd fd fd fd ab ab ab ab ab
// DWORD dwFlags = STRSAFE_FILL_BYTE('X') | STRSAFE_NO_TRUNCATION;

// The MEMORY content after the StringCchCopyEx executing:
// 00 00 53 00 44 00 46 00 00 00 fd fd fd fd ab ab ab ab ab
DWORD dwFlags = STRSAFE_FILL_BYTE('X') | STRSAFE_NULL_ON_FAILURE;

HRESULT result = StringCchCopyEx(buffer, charsCount, pSrc, &pDestEnd, &remaind, dwFlags);

For both cases the memory has the same content... What the difference for the STRSAFE_NO_TRUNCATION and STRSAFE_NULL_ON_FAILURE values?

Answer 1

A safe string function with confuzzling documentation, what could go wrong? The difference between the two is exactly where the zero-terminator is written when you also use STRSAFE_FILL_ON_FAILURE with a non-zero filler:

• Use STRSAFE_NO_TRUNCATION if you want to see the filler in the resulting string, the zero is written at the end.
• Use STRSAFE_NULL_ON_FAILURE to always get an empty string. The filler is still written but past the 0.

Do beware of a flaw in the way the filler works. The probably reason behind the confusing docs. It can only be a value between 0 and 255, that of course can only really work properly for StringCchCopyExA(). The Unicode version will produce Chinese, "塘塘塘塘" in your case, pretty much forcing you to use 0 as the filler. In which case there is indeed no difference anymore and the docs are accurate enough.