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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers