oops.
Ralph Corderoy wrote:
...
There was a long `strncpy(3), die, die, die.' thread back in 2016 about
this, including that strncpy() pads to the full 8 KiB with NULs. My
to-do list summarises what I think was the conclusion.
- Add trunccpy() for when truncation is correct, e.g. the start of a
long string back to the user in an error message. [Done.]
void trunccpy(char *dst, const char *src, size_t size);
/* A convenience for the common case of dst being an array. */
#define TRUNCCPY(dst, src) trunccpy(dst, src, sizeof (dst))
- Add uvstrncpy(), an `unvetted' strncpy() that dies or warns when
truncation occurs and always ensures the destination is
NUL-terminated. The choice of death, warning, or silence is at
run-time.
- Add strpadcpy() that gives strncpy()'s truncating, padding,
behaviour.
- Replace all strncpy() with uvstrncpy().
- Examine the unvetted uvstrncpy() and replace with one of the
alternatives.
i still love this plan.
The global search/replace of strncpy() is going to mess up
cherry-picking, folks' unpushed commits, etc., so I've avoided doing it,
but it looks like GCC 8.0, when it's released, might force the issue.
let's just declare a date and do it. waiting hasn't bought us much.
As for the related snprintf(), etc., well, at least destination is NUL
terminated, even if the truncation could cause data loss. They too need
looking at and replacing in time.
uvsnprintf() could be implemented in terms of asprintf(), strlen(),
strcpy(), and free(). and if your uvstrncpy() project succeeds, as i
predict it will, then this is what i'll recommend.
--
P Vixie
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers