Hi, Valdis wrote: > I'd be quite surprised if we don't have at least one off-by-one error > in there.
Separate from those errors, a lot of the code doesn't care if the char[] ends up unterminated and continue to use the result assuming it is. IOW, it assumes the char[] is `big enough', and at 8 KiB it often is. 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. 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. 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. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers