The so-called 'safe' strncpy and memcpy functions are nothing of the sort - either way, you have to keep track of the buffer.
- If you forget how large the destination is, the 'safe' versions still give you a buffer under/overrun because they do not check the actual target, instead they check that the size you said it was meets the requirement to send the data you're specifying.
So the only situations they catch is when you do something like
strncpy_s(dst, 5, "a long string", 5);
- This throws an error as there's no space for the NUL
However, if you do
strncpy_s(dst, 5, "a long string", 4);
- if dst only has space for 3 characters, then strncpy_s succeeds but you still have a buffer overflow.
Finally, and most disturbingly, srtncpy_s still has undefined behaviour if Src and Dest overlap - if it handled that one, I'd accept it as an improvement. As it is though, it's simply a slowdown for no gain.
In other words, they are simply a marketing gimmick from Microsoft - this is why none of the other runtime libraries include them.
You know where the data came from, you know how big your buffer is, so check it yourself. If you're not checking it, then you're being a muppet and the 'secure' versions won't save you anyway.