Hi,
Ken wrote:
What if benign truncations were trunccpy(), instead of the
strncpy dance where the reader is unsure if it's benign or not,
and then abortcpy() could be the strncpy() replacement that aborts
on truncation, with all the previously mentioned get-a-rounds?
Obviously, abortcpy is bad and should be sought and destroyed over
time, but meanwhile it puts strncpy into one of two camps, with the
remaining strncpy standing out as still needing analysis.
Sounds great to me.
Pushed.
commit fd3910e3f5d137e0c2938d33c39effd677444419
Author: Ralph Corderoy <ralph@inputplus.co.uk>
Date: Sun May 23 14:32:39 2021 +0100
sbr/utils.c: add abortcpy() which prefers to abort than to overflow.
This is the partner to trunccpy(). If truncation is valid, e.g. passing
on the first part of a long string in an error message, then trunccpy()
should be used instead of strncpy(3). Else abortcpy() should be used
as it will abort(3) rather than overflow the destination or leave the
destination not terminated.
(strncpy() is rarely wanted as its NUL-padding is only useful to pad
fixed-width fields, e.g. an old 14-byte filename which sits alongside
the 16-bit inode number in a directory entry.)
The creation of abortcpy() and its environment-variable workaround was
discussed on nmh-workers around 2016-10-29, in particular message-ID
<20161029214059.1046247BE8@pb-smtp2.pobox.com> at 21:40:58 UTC.
I realised some trunccpy() and TRUNCCPY() may have been put in place which
should have been the abort version because truncation is not permitted
so dug into the mailing list and found Ken's agreement. Now the function
exists, I'll revisit the truncating ones and double-check they shouldn't
be aborting.
BTW, the age of this thread points to the slow progress in some areas
of nmh. If there's any dot-com got-out-in-time millionaire, BTC hodler,
or heiress who's soon to inherit on the list who fancies funding a little
development to speed it up, don't be shy! :-)
--
Cheers, Ralph.