4 ms·

strncpy() is not a "safer" strcpy(). It can avoid some errors involving writing past the end of the target array (if you tell it the correct length for that arr

• icedchai 6y ago
  This is true, and many people don't realize it. I used to call a wrapper function that would always set the last byte to 0.
• rrauenza 6y ago
  I never could really understand the point of strncpy()... we always end up wrapping to deal with writing an unterminated string. Was it intended for fixed length records?
  • tedunangst 6y ago
    It is for fixed length records, which is why it also zeroes the remaining space.
    • ironmagma 6y ago
      Arguably naming it with “str” is itself a security vulnerability.
      • tedunangst 6y ago
        No argument. At best it is a "string to fixed record" function, hence the name, but it is not a string function.
  • Someone 6y ago
    Yes. strncpy was intended for copying file names into a buffer that was only zero terminated when the name was shorter than the maximum length of a file name in Unix (14 bytes. See https://stackoverflow.com/a/1454071 https://stackoverflow.com/a/1454071, https://devblogs.microsoft.com/oldnewthing/20050107-00/?p=36773 https://devblogs.microsoft.com/oldnewthing/20050107-00/?p=36...) You can also use it to overwrite part of an existing string, but I think that’s a side effect of the above.
  • deleted 6y ago
    [deleted]
  • spc476 6y ago
    Yes it was. On early Unix systems, each entry in a directory was bascially: struct dir { char name[14]; int inode; }; Adding a NUL byte might waste a full byte that could otherwise be used---remember, back when C was first developed, 10M disks were large and very expensive.
• throwaway09223 6y ago
  In the interest of satisfying pedantry I think we can agree that strncpy() is intended to be a safer strcpy() for a subset of uses. As you say, it does in fact obviate some errors. A value judgement as to which behaviors are more or less safe may be subjective, but the intent is not.
  • wahern 6y ago
    strncpy was never intended to be a safer strcpy. It was created for a very specialized use case in the Unix kernel--copying a string-ish identifier to a fixed-size char field that only uses NUL termination if the identifier is shorter than the field size. Because of how the C language and the Unix kernel coevolved, it became part of the standard C library by default. I've seen it used for it's original semantics in only a handful of places, but in general it's almost always misused. To be clear, strncpy does not guarantee NUL termination. It takes a C string as the source argument, but it doesn't write out a C string; it writes out a very esoteric data structure that is unfortunately easily confused with a C string. By contrast, strlcpy was intended to be a safer string copy routine: https://www.usenix.org/legacy/event/usenix99/full_papers/millert/millert.pdf https://www.usenix.org/legacy/event/usenix99/full_papers/mil... In particular, it was designed to be what people seem think strncpy is. Its return value semantics are controversial, though mostly only among the glibc crowd as every other Unix libc, including musl and Solaris, now provide it. But the semantics were designed based on experience in fixing old C code, and observations about how developers tend to write C code, not based on prescriptive theories about how people should manipulate C strings in C code.