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

[Ralph Corderoy]

Hi Ken,

> You know, somehow I had missed all of these years that strncpy() pads
> out the rest of the buffer, which is certainly not ideal!

Yes, I keep forgetting it and rediscovering.  :-)

> I can only say that on my Linux systems, I don't have strlcpy() or
> -lbsd.

Here it's provided by package libbsd that was pulled in by
openbsd-netcat, smbclient, ...  http://libbsd.freedesktop.org
But it's a trivial function.

> However, the current situation isn't ideal.  But this gets into some
> deeper questions - like, if we are truncating a "string", does the
> character set matter?

Yes.

> Also, what should we do when a string is truncated?  I'm not so crazy
> about our current behavior of calling exit() inside of a lot of
> library functions.

Me neither.  But the doing that is arguably better than silently passing
on truncated data, perhaps a string that's invalid under the encoding.

> I suspect a lot of the time we don't care if truncation happens, or
> more accurately there isn't really a great solution.

Rewrite that bit of code where it can happen to use dynamic allocation?
But that's a big leap from today's code for all strncpy calls.

> I dunno, I think we'd need to think carefully if a particular use of
> strncpy() really warrants an abort vs a truncate.

There may be cases that truly aim for a truncate, yes.  Either they'll
be spotted and left alone.  Or wrongly coverted, blow up, and be
reverted.  Given I think few want a truncate, I'm hoping not many
reversions will be needed.

> I mean, just crapping out on a really long line that other MUAs handle
> just fine seems rather unfriendly to me.

Agreed.  But crapping out breaks the silence so that area can be worked
on.  At the moment, there's many strncpy calls and they can't all be
rewritten to be malloc or something else.  Another alternative is
reporting on stderr, though spew from a loop would be annoying.  Perhaps
the truncating-copy routine could stop reporting after a few.  When
they're fixed, the next ones will project.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy