6 ms·

tl;dr: strncpy() doesn't null terminate, but doesn't mention strlcpy() http://www.openbsd.org/cgi-bin/man.cgi?query=strlcpy http://www.openbsd.org/cgi-bin/man.

• masklinn 11y ago
  Because, much like reallocarray, strlcpy is not part of the C standard library. The correct solution, assuming you can't just import libbsd or include its functions, is probably to use snprintf. It goes guarantee null-termination of the target. So strncpy(dst, src, size_dst); becomes snprintf(dst, size_dst, "%s", src); Checking for partial copy is not ideal though, snprintf returns the number of bytes it would have copied had the destination buffer been infinite excluding the final NUL byte. So a copy is only complete if `ret < size_dst`. snprintf is not available in C89 though...
  • rkangel 11y ago
    Or just to add an implementation of strlcpy in a util module in your codebase. e.g.: http://mirror.fsf.org/pmon2000/3.x/src/sdk/libc/string/strlcpy.c http://mirror.fsf.org/pmon2000/3.x/src/sdk/libc/string/strlc...
    • masklinn 11y ago
      Hence > assuming you can't just import libbsd or include its functions
      • lmm 11y ago
        Under what circumstances would you ever be unable to copy such a small and liberally-licensed file into your source?
        • nitrogen 11y ago
          If, for whatever reason, you don't want to have anyone else's copyright on your product, or don't want to keep track of which licenses have to be displayed where.
  • jjnoakes 11y ago
    snprintf is also slower. It has to parse the format string. Just use strncpy and NUL-terminate the buffer. It's not hard. Write a two line function to do it for you, and use that function in place of strncpy.
    • _kst_ 11y ago
      dest[0] = '\0'; strncat(dest, src, size);
      • jjnoakes 11y ago
        Sure. Or: strncpy(dest, src, size); dest[size - 1] = '\0';
        • nitrogen 11y ago
          The fact that strncpy zeros the buffer may make it slower.
          • jjnoakes 11y ago
            Sure, by a couple of cycles. Unless your size is huge. In which case, perhaps you should try to avoid copying strings in the first place.
    • masklinn 11y ago
      > Just use strncpy and NUL-terminate the buffer. It's not hard. Just as it's not hard to not dereference null pointers, not double-free allocations and a truckload of other mindless drudgery which history shows humans won't reliably get right all the time. Not to mention checking for copy truncation with strncpy is error-prone, you've got to check whether it points to a `\0` before you manually null-terminate it, providing more chances to get it wrong. > snprintf is also slower. It has to parse the format string. How about worrying about that when snprintf actually shows up in profiles and there's no algorithmic way to improve the situation and strncpy is a significant improvement?
• MrBuddyCasino 11y ago
  I'm not a C programmer, but even I knew that strlcpy() and snprintf() would come up in this discussion. How fucked up is that? Is there a resource where these issues are answered once and for all, for the novice C programmer? Also, are there deprecation warnings emitted by the compiler for non-safe C stdlib functions?
  • clarry 11y ago
    On OpenBSD the linker whines about uses of unsafe functions. I don't see it becoming mainstream though, as there are so many people who disagree about what's unsafe.
  • lawl 11y ago
    Not a C programmer either. But I've seen projects banning strcpy. The code was littered with strncpy(a, b, strlen(b)). So I'm not sure how useful these warnings would be.