False sense of security with `snprintf_s`

问题:

MSVC's "secure" sprintf funcions have a template version that 'knows' the size of the target buffer. However, this code happily paints 567890 over the stack after the end of bytes...

char bytes[5];
_snprintf_s( bytes, _TRUNCATE, "%s", "1234567890" );

Any idea what I do wrong, or is this a known bug?

(I'm working in VS2005 - didn't test in 2008 or 2010)

回答1:

It does appear to be a bug in Visual C++ 2005 (I'm having trouble getting to that link; Google also has it cached).

I was able to reproduce the problem in Visual C++ 2005. In Visual C++ 2008 and 2010, the string is correctly truncated (bytes contains 1234\0) and -1 is returned as expected.

回答2:

The example is indeed correct. As of version --

Microsoft Visual Studio 2005
Version 8.0.50727.867 (vsvista.050727-8600)
...
Visual C++ 77626-009-0000007-41722

-- which includes SP1, the vista hotfix and a few of the library hotfixes -- the above mentioned function

template <size_t size>
int _snprintf_s(
   char (&buffer)[size],
   size_t count,
   const char *format [,
      argument] ... 
);

still is buggy. However, what is really fascinating is that only this function of the 4 variant functions

• OK: int _snprintf_s(char *buffer, size_t sizeOfBuffer, size_t count, :::
• Buggy: template <size_t size> int _snprintf_s(char (&buffer)[size], size_t count, :::
• OK: int _snwprintf_s (wide character version)
• OK: template <size_t size> int _snwprintf_s (yes, the wide character version is OK)

is buggy, that is if one's using the non-template version it's OK, and if one's using either of the wide character versions it's OK too. Amazing.

回答3:

Example was wrong.

The code should be:

char bytes[5];
_snprintf_s( bytes, 5, _TRUNCATE, "%s", "1234567890" );

For the wrong code, it may a bug that the compiler did not give any warning but it would be the weak checking for snprintf.