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?

(well, from a BSD perspective. Apparently strcpy_s has been around on Windows since Windows 95.)