The _s family of functions is what MSVC has been forcing upon people by claiming all other functions deprecated.<p>So now the standard is lending nomenclatura and possibly implementation from the company that stoically refuses to implement C99.
Using <i>strncpy</i> is not a remedy at all. The function was never designed for safe string copying, but for copying fixed-width inode names[1]. The fact that is protects against buffer overflows is pure coincidence.<p>[1]: <a href="http://stackoverflow.com/a/1454071" rel="nofollow">http://stackoverflow.com/a/1454071</a>
The only difference between strcpy_s and strlcpy, other than taking arguments in a different order and being more annoying to type, is that if an overflow would occur, it sets destination[0] to 0 rather than truncating. This is probably an improvement, since truncation can cause security problems if you're building filenames and such (though, should you fail the test accidentally, I suspect it's much harder to track down why a string somewhere in your app became empty than why it was truncated)... but is it really worth switching to yet another string copy function?<p>(well, from a BSD perspective. Apparently strcpy_s has been around on Windows since Windows 95.)
The author/site mentions that in practice snprintf isn't portable on Unix platforms because a number of implementations of it are botched. I have to say that one of the best things we did was implement our own conforming printf/scanf family of functions. They act the same everywhere, which isn't possible even with the existing conforming C library implementations, as the Standard is not precise about the specification.