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
