Hi David,
I hope this strncpy thread doesn't run on for ever and anon.
It's delaying my brace-style email.
I dunno, I think we'd need to think carefully if a particular use of
strncpy() really warrants an abort vs a truncate. I mean, just
crapping out on a really long line that other MUAs handle just fine
seems rather unfriendly to me. What do others think?
I'm not a fan of abort, either, unless it shows the context. That
might not be trivial with multibyte characters, but should be doable.
What if we consider the s/strncpy/trunccpy/ a diagnostic aid for the
existing code? The call site won't change much: the size will including
the NUL so sizeof doesn't need adjusting; trunccpy will always store
the NUL so the next line doesn't need to be the NUL assignment.
The function can also be passed __FILE__ and __LINE__ for reporting when
it truncates. And it can report details of the truncated too, assuming
one-byte-per-rune (codepoint) encoding and escaping !isprint. A macro
can handle passing size and source location for the common case.
TRUNCCPY(buf, addr);
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers