1. 17
  1. 3

    strlcpy is identical to the sprintf invocation from before, except it uses the correct size_t return type. This still means it fails to satisfy the performance requirements of 3 and 4

    This isn’t true. I don’t know why this person thinks strlcpy is implemented in terms of snorintf, but of course it isn’t; that would be silly. I haven’t seen the implementation, but I have no reason to assume its performance is less than the optimized code at the start.

      1. 1

        What interface works best depends on your use. Are you reallocating the destination buffer if it is too small? Are you concatenating a lot of strings? Are you scanning a buffer copying out substrings?

        Performing a strlen like this one can be dangerous because people might end up with accidentally quadratic code.

        1. 2

          Totally fair point! However even for such simple but critical functions I prefer to use a bullet-proofen implementation which strlcpy(3) and strlcat(3) are.

    1. 2

      Return value:

      In the case where src fits in dst, it will return a pointer past the NUL byte it placed; otherwise it returns NULL to indicate a truncation.

      Why past the NUL byte it placed, and not on it? This is equivalent to returning the number of bytes written (if you subtract dst), instead of the length of the destination string, but the latter is often more useful.