News for hackers. Stuff that matters.
Re:Beware of strncpy and strncat by nneonneo on Wednesday June 06, 2018 @01:35PM (#17249208)
The advice given in this article is bad. Reducing the length of the copy by one will still fail to null-terminate the string if the source exceeds the destination length. You need to add

    dst[sizeof(dst)-1] = 0;
or memset the array to zero beforehand. You are not guaranteed to have a zero at the end of the input buffer otherwise (neither local variable arrays nor malloc’d arrays are guaranteed to be zeroed).

strncpy sucks for a second reason: it writes n bytes no matter what the source is. That means if you write

    char buffer[16384];
    strncpy(buffer, “hello”, sizeof(buffer)-1);
    buffer[sizeof(buffer)-1] = 0;
this will fill 16K of memory with zeroes despite only needing to copy a 6-byte string.

strlcpy/strlcat do the right thing (copy up to n-1 bytes and null-terminate); shame they aren’t standardized. In their absence, I suggest snprintf instead:

    snprintf(buffer, sizeof(buffer), “%s”, src);
Because snprintf returns the number of bytes that would be written, it can be used to detect overlong input strings, reallocate the buffer as necessary, and also to implement efficient concatenation. It’s also surprisingly fast in most implementations.
Re:Beware of strncpy and strncat by beeforpork on Wednesday June 06, 2018 @01:47PM (#17249324)
Same advice everywhere, very good, my words exactly: use snprintf().

But beware of old MS _snprintf:

https://docs.microsoft.com/en-us/previous-versions/visualstu...

Re:Beware of strncpy and strncat by blattimwind on Wednesday June 06, 2018 @02:35PM (#17249782)
> The advice given in this article is bad.

Thumbing through previous submissions of this domain with discussion, this seems to be a pattern.

Re:Beware of strncpy and strncat by belorn on Wednesday June 06, 2018 @02:56PM (#17249973)
Its a shame that many of the solution to those exist as non-standardized calls and seems split between BSD and GNU. Personally I use asprintf quite a lot, and I recall strndup to be quite useful to create a identical copy of a buffer. strndup should have an identical performance to allocating a buffer and then strlcpy, since it too do copy up to n-1 bytes and null-terminate.
Re:Beware of strncpy and strncat by loeg on Wednesday June 06, 2018 @04:01PM (#17250567)
It's a shame they aren't in ISO C, but strdup and strndup are at least standardized by POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/st...
Re:Beware of strncpy and strncat by kdelok on Wednesday June 06, 2018 @02:46PM (#17249889)
Is there any reason not to use snprintf for almost every application of string manipulation (aside from strduping)?
Re:Beware of strncpy and strncat by hxchen on Wednesday June 06, 2018 @03:33PM (#17250312)
Reason: performance.

If you just do string manipulation, memncpy is faster.

If you need to convert data type, like int to string, then use snprintf.

Re:Beware of strncpy and strncat by nneonneo on Wednesday June 06, 2018 @05:07PM (#17251130)
Yes, it seems I lied when I said sprintf is surprisingly fast. For most practical purposes it's fine, but if you need to do string manipulation in a hurry, strcpy/strlcpy are going to be faster.

See https://gist.github.com/nneonneo/f9dc5c1d1d342d25eae47d56dba... for a test harness. On my Mac, with a 16-byte string, 10 million loops:

    memcpy:     77406 us
    strlcpy:   101956 us
    strncpy:   177247 us
    sprintf:   730819 us
    snprintf:  699844 us
memcpy smokes sprintf - around 10x faster. The vast majority of sprintf's time is spent in setup; for large strings, the gap closes substantially.
Re:Beware of strncpy and strncat by hxchen on Wednesday June 06, 2018 @03:36PM (#17250338)
Or use calloc. It does the same thing as malloc, but init memory to zero automatically.
Re:Beware of strncpy and strncat by tinus_hn on Wednesday June 06, 2018 @04:01PM (#17250568)
If you’re going to allocate the memory you might as well just use the library functions that allocate exactly the space you need and copy the string into it. These tricks are for when you use the stack as an ‘optimization’.
Re:Beware of strncpy and strncat by laythea on Wednesday June 06, 2018 @01:45PM (#17249313)
strncpy would have to assume that it was working on strings if that were not the case.....oh wait....