There are two non-ideal properties of this replacement for general use, although perhaps neither of them applies to the curl codebase.
1. If you're copying a very short string from a large buffer to another large buffer, e.g. if values are typically a couple of characters but you support 65536 chars or more for pathological cases, you will memcpy the whole buffer every time.
2. If you take a string, chop the end off with s[i] = 0, then curlx_strcopy it into a fresh data structure, you might be surprised that leak the end of the string you chopped off (and more generally any uninitialised memory in a buffer beyond the end of a string) into the new struct. Don't send that struct out over the network or pipe it to a less-privileged process.
There are two non-ideal properties of this replacement for general use, although perhaps neither of them applies to the curl codebase.
1. If you're copying a very short string from a large buffer to another large buffer, e.g. if values are typically a couple of characters but you support 65536 chars or more for pathological cases, you will memcpy the whole buffer every time.
2. If you take a string, chop the end off with s[i] = 0, then curlx_strcopy it into a fresh data structure, you might be surprised that leak the end of the string you chopped off (and more generally any uninitialised memory in a buffer beyond the end of a string) into the new struct. Don't send that struct out over the network or pipe it to a less-privileged process.