I think memccpy is an improvement, so I support it, but it's still complicated to use in practice. The article gives this example for a copy followed by concate

I think memccpy is an improvement, so I support it, but it's still complicated to use in practice. The article gives this example for a copy followed by concatenation: char *p = memccpy (d, s1, '\0', dsize); dsize -= (p - d - 1); memccpy (p - 1, s2, '\0', dsize); Notice that you have to recalculate dsize (correctly without one-off errors!), it assumes you have dsize itself, and this doesn't detect overruns (which in many cases you should do). So real-world code would look more like this: // dsize is the space *available* in d, including \0 size_t dsize = sizeof(d); // if d is an array // ... char *p = memccpy (d, s1, '\0', dsize); dsize -= (p - d - 1); if (dsize <= 0) goto overflow; // handle overflow char *q = memccpy (p - 1, s2, '\0', dsize); dsize -= (q - (p - 1) - 1); if (dsize <= 0) goto overflow; // handle overflow It's a little easier to understand than strncat/strncpy versions, it doesn't unnecessarily read its inputs past where they are needed like strlcat/strlcpy do, and it's more efficient than snprintf. So yes, it's an improvement and I support it. However, this is still rather complex; in particular, it's way harder to understand compared to code that uses snprintf, and certainly harder to understand than pretty much any other programming language higher level than assembly. So let's accept this improvement, and keep striving to do better.