We do everything we can to avoid removing comments; however, comments that contain negative statements aimed at an individual will be removed becaue they violate this sites Acceptable Usage Policy. You can comment on the code and the article, but please keep comments towards people professional.
"Actually there are already such functions in Windows"
Indeed, but when I came with the idea of using them, from different reasons my boss decided to avoid the introduction of these functions after the middle of the current version lifetime (in the last 2-3 project iterations). Itbs obviousb&
Maybe it has sense to consider a template function too instead of your 'usprintf' macro? This is an attempt for Unicode strings:
template< size_t SIZE >
bool usprintf(wchar_t (&buffer)[SIZE], const wchar_t * format, ...)
bool success = _vsnwprintf(buffer, SIZE, format, argptr) >= 0;
if( ! success) buffer[SIZE - 1] = 0;
It works with buffers allocated on stack and calculates automatically the bufferbs size.
Actually there are already such functions in Windows.
Please watch your comments. You can freely debate whether code is right or wrong and whether the article presents information in a useful way or not. What you cannot due is post negative comments about others. There is no place for comments like "how dumb can you be," "Crawl back under your rock...," etc.
Discuss the technology, not the technologist.
Please do not respond to this off topic comment. If you have a further issue you want me to address, freel free to contact me via the forum or via webmaster@ this site's domain name.
"Instead of simply fixing the size by using _countof() at the location of the original call"
1st using _countof() with swprintf() is not proper (out of the case you want to add the count value in buffer).
On the other side it's hard to add _countof() in a huge solution for each _snwprintf() and that's why we used some macros.
"you now have a macro everywhere which the maintenance programmer will have to look up"
The cost of a new team member looking over a simple macro like this is insignificant comparing with the situations when your product is crashing to customers (just because in some situation the buffer limit(2048) was . :)
As I said in article, I started from a concrete situation when I had to analyse different .dump files and those files were created by issues like this.
"Did I understand it right now, or am I still missing something?"
It seems you have a too small overview and I don't try to convince you any more as long as you don't know me in person but you dare to qualify me in different ways.
Any other discussion is redundant and out of topic.
Have a nice day!
Oh wait, I see what you're trying to do. You're trying to say that you knew all along what the prototype of swprintf() was, but that you were actually trying to prevent people from lying about the size of the buffer. Awesome. Simply awesome.
The functions used in the macro (_snwprintf/_snprintf()) are not proper to replace functions like vswprintf() - this function has different count of mandatory parameters and uses a list of arguments parameter.
Sorry, in article I mean swprintf() witch is unsafe. Thanks for observation.
"Using vsprintf, here is no way to limit the number of characters written, which means that code using this function is susceptible to buffer overruns. Use _vsnprintf instead, or call _vscprintf to determine how large a buffer is needed. Also, ensure that format is not a user-defined string. For more information, see Avoiding Buffer Overruns." Same story with vswprintf().