Actually, there are big problems with strcpy_s and strcat_s. First, strcpy_s abort()s the process if there would have been an overflow, making it useless for most programs. Second, Microsoft already has a function named strcat_s, and it behaves differently than the spec.

Here's VC++'s strcat_s:

    errno_t strcat_s(
        char *strDestination,
        size_t numberOfElements,
        const char *strSource 
    );

In VC++, numberOfElements is the size of strDestination. In the C11 spec, that parameter is the maximum number of bytes to copy into strDestination. People are going to search for strcat_s docs, find the MSDN page, and write buffer overflows.

If strlcpy/strlcat aren't available on a target platform, I stick them them in a util.h/util.c, wrapped in #ifndefs. Like so: https://github.com/ggreer/the_silver_searcher/commit/a43dc87...

> Actually, there are big problems with strcpy_s and strcat_s. First, strcpy_s abort()s the process if there would have been an overflow, making it useless for most programs

aborting is correct: unexpected truncation is always a logic bug. Truncation can lead to unexpected behavior, so better to fail fast than to get into a state about which you probably haven't reasoned. If you really want strlcpy-like truncation, use strncpy_s (which, unlike strncpy, acts sanely with respect to NUL termination and filling). Of course, on untrusted input copied into a fixed-size buffer, you should be using strncpy_s instead of aborting. Use the right tool for the job.

> In VC++, numberOfElements is the size of strDestination. In the C11 spec, that parameter is the maximum number of bytes to copy into strDestination.

That's not actually a distinction. The purpose of the function is to ensure that the code writes no more than numberOfElements bytes into strDestination. Both versions of the function do that.

Note that the wide character versions of these functions are both specified in number of elements. (So are the narrow character versions, but the difference in moot because sizeof(char) == 1).)

> If strlcpy/strlcat aren't available on a target platform, I stick them them in a util.h/util.c, wrapped in #ifndefs.

Or you can use https://slibc.googlecode.com/svn/api-doc/html/index.html

"aborting is correct: unexpected truncation is always a logic bug"

How does a function knows what a programmer expects... A lot of use for those potentially truncating functions are for display purpose, where truncating is expected and not a logic bug...

A library function potentially exiting is mostly useless.

And as the GP said, for those cases that truncating is expected (or not a problem) then use strncpy_s.

aborting is a terrible, terrible way to signal an error. strlcpy has a return code to report truncation. Discipline around return codes is already required in C. It's not a huge burden to bear (and if you're doing it right there should be lints to detect when checks are missing).