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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers