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

[Ken Hornstein]

>This leaves s NUL terminated, but possibly silently truncated.  Also, if
>addr is a lot shorter than BUFSIZ, 8KiB here, then strncpy NULs out all
>the rest of the 8KiB past the end of the string's terminator NUL.  I'd
>think that's not needed by most of the callers, though it's difficult to
>know without examining each case.

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

>I was thinking of switching to strlcpy(3) from BSD, also available on
>Linux with -lbsd or similar.  A stand-in if it's not available is
>trivial.  The autoconf less so, but seemingly do-able.
>http://lists.windowmaker.org/dev/msg01783.html

I can only say that on my Linux systems, I don't have strlcpy() or
-lbsd.  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?  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.  I suspect a lot of the
time we don't care if truncation happens, or more accurately there isn't
really a great solution.

>«snprintf(s, sizeof s, "%s", addr)» is the equivalent.  Both would
>shorten the code back to one line, so less to review, but both would
>still silently truncate.
>
>So how about our own function that takes (dest, src, size) and if
>strlen(src) isn't less than size then it abort(3)s.  So, it's a checking
>strcpy, no more.  A macro for the common case of size being dest's
>sizeof will remove the last bit of repetition.

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?

--Ken