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