Re: [Nmh-workers] strncpy(3), die, die, die.

[Ralph Corderoy]

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