\nMany functions accept a source string that consists of both a pointer\nand a length.\nAnd if you pass a length that is greater than the length of the string,\nthe result depends on the function itself.\n<\/p>\n
\nSome of those functions, when given a string and a length, will stop\neither when the length is exhausted or a null terminator is reached\nwhichever comes first<\/i>.\nFor example, if you pass a \nOn the other hand, many other functions (particularly those in the\nNLS family)\nwill cheerfully operate past a null character if you\nask them to<\/i>.\nThe idea here is that since you passed an explicit size,\nyou’re consciously operating on a buffer which might\ncontain embedded null characters.\nBecause, after all, if you passed an explicit source size,\nyou really meant it, right?\n(Maybe you’re operating on a \nI’ve seen programs crash because they thought that functions\nlike \nThe intent here was for \nCritique, then, this replacement function:\n<\/p>\ncchSrc<\/code> greater than the\nlength of the string to the\nStringCchCopyN<\/code> function, it will stop at the null\nterminator.\n<\/p>\nBSTR<\/code>, which supports\nembedded nulls; to get the size of a BSTR<\/code> you must\nuse a function like SysStringLen<\/code>.)\nFor example, if you call\nCharUpperBuff(psz, 20)<\/code>, then the function\nreally will convert to uppercase 20 TCHAR<\/code>s\nstarting at psz<\/code>.\nIf there happens to be a null character at psz[10]<\/code>,\nthe function will convert the null to uppercase and continue\nconverting the next ten TCHAR<\/code>s as well.\n<\/p>\nCharUpperBuff<\/code> and\nMultiByteToWideChar<\/code>\nstopped when they encountered a null.\nFor example, somebody might write\n<\/p>\n\n\/\/ buggy code - see discussion\nvoid someFunction(char *pszFile)\n{\n CharUpperBuff(pszFile, MAX_PATH);\n ... do something with pszFile ...\n}\nvoid Caller()\n{\n char buffer[80];\n sprintf(buffer, \"file%d\", get_fileNumber());\n someFunction(buffer);\n}\n<\/i><\/pre>\nsomeFunction<\/code>\nto convert the string to uppercase\nbefore operating on it, up to MAX_PATH<\/code> characters’ worth,\nbut instead what happens is that the MAX_PATH<\/code> characters\nstarting at pszFile<\/code> are converted, even though the\nactual buffer is shorter!\nAs a result, MAX_PATH<\/code> − 80 = 220\ncharacters beyond the end of buffer<\/code> are also converted.\nAnd since that’s a stack buffer,\nthose bytes are likely to include the return address.\nResult: Crash-o-rama.\nThings get even more interesting if the short buffer had been allocated\non the heap instead.\nThen instead of corrupting your return address (which you would\nprobably notice as soon as the function returned),\nyou corrupt the heap,\nwhich typically doesn’t manifest itself in a crash until long after\nthe offending function has left the scene of the crime.\n<\/p>\n\n\/\/ buggy code - do not use\nint invariant_strnicmp(char *s1, char *s2, size_t n)\n{\n \/\/ [Update: 9:30am - typo fixed]\n return CompareStringA(LOCALE_INVARIANT, NORM_IGNORECASE,\n s1, n, s2, n) - CSTR_EQUAL;\n}<\/i>\n<\/pre>\n