[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: Sat, 29 Oct 2016 17:06:15 +0100

Hi Paul,

> > Perhaps a complainant could be told of the secret $NMHNOBARF to stop
> > TRUNCCPY from aborting?  Though it would still complain for the
> > first N goes?
> replacing overrun with truncation is not a big enough improvement to
> justify touching the code at all.

I'm targetting the existing truncations, not overruns, e.g. it's

    strncpy(sm_reply.text, str, sizeof(sm_reply.text));
    sm_reply.text[sizeof(sm_reply.text) - 1] = '\0';

strncpy's dest is often 8KiB and it pads that with NULs.  I think a new
function can replace that two-line pattern, and a macro can save the
last bit of duplication in the common sizeof-1 case.

    trunccpy(sm_reply.text, str, sizeof sm_reply.text);

    TRUNCCPY(sm_reply.text, str);

Truncating is bad.  trunccpy would abort() by default rather than return
a truncated string.  Because a user might be stuck with this abort
version of nmh for a long time, it can be overridden by an environment
variable to have it stderr-warn for the first small-N goes instead,
before falling silent.

This behaviour is no worse than now.  It is better IMO because it won't
pad in the common no-truncation case, and it won't silently truncate.
It's implementable with simple impact on the call sites and thus easy to
eyeball, unlike handling news that dest is too small.  By identifying
the strncpys that currently silently truncate and continue processing
and replacing them with this explicit "I truncate and that's bad"
function it will make them targets for a better fix as some analysis has
already been done;  akin to adding a FIXME comment.

Cheers, Ralph.

reply via email to

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