[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ralph Corderoy
Subject: Re: [Nmh-workers] strncpy(3), die, die, die.
Date: Mon, 24 Oct 2016 22:31:48 +0100

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]