Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC] strcpys(): New function for copying strings safely
From:   "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To:     David Laight <David.Laight@ACULAB.COM>,
        glibc <libc-alpha@sourceware.org>
Cc:     "tech@openbsd.org" <tech@openbsd.org>,
        Christoph Hellwig <hch@lst.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        drepper@gmail.com
References: <755875ec-baae-6cab-52a8-3c9530db1ce6@gmail.com>
 <38428d5e-ead2-bf18-e198-cecd4caeb3e7@gmail.com>
 <f5bfab0dce604736b6a563a4f9f7ce43@AcuMS.aculab.com>
 <52e57bd5-0d04-4b4f-978a-8c1dbc08115c@gmail.com>
Message-ID: <d27912e6-f090-68af-295d-d40b00c1b0a7@gmail.com>
Date:   Mon, 28 Jun 2021 14:00:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <52e57bd5-0d04-4b4f-978a-8c1dbc08115c@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 6/28/21 1:32 PM, Alejandro Colomar (man-pages) wrote:
>>
>> The other use is where you want a sequence of:
>>     len *= str_copy(dest + len, dest_len - len, src);
>> But don't really want to test for overflow after each call.
> 
> This is a legitimate use of strscpy().  Please, add it to glibc, as 
> there is no libc function to do that.
> 
>>
>> In this case returning the buffer length (including the added
>> '\0' on truncation works quite nicely.
>> No chance of writing outside the buffer, safe truncation and
>> a simple 'len == dest_len' check for overflow.
>>
>> OTOH there are already too many string copy functions.
> 
> There are, but because the standard ones don't serve all purposes 
> correctly, so people need to develop their own.  If libc provided the 
> necessary functions, less custom string copy functions would be 
> necessary, as Christoph said a long time ago, which is a good thing.
> 
> As I see it, there are the following, each of which has its valid usage:
> 
> strcpy(3):
>      known input && known buffer
> strncpy(3):
>      not for C strings; only for fixed width buffers of characters!
> strlcpy)3bsd):
>      known input && unknown buffer
>      Given that performance-wise it's similar to strscpy(),
>      it should probably always be replaced by strscpy().
> strscpy():
>      unknown input && truncation is silently ignored
>      Except for performance-critical applications,
>      this call may replace strcpy(3), to add some extra safety.
> strcpys():
>      unknown input && truncation may be an error (or not).
>      This call can replace strscpy() in most cases,
>      simplifying usage.
>      The only case I can see that strscpy() is superior
>      is for chains of strscpy(), where I'd only use strcpys()
>      in the last one (if any strscpy() in the chain has been
>      trunncated, so will the last strcpys() (unless it's "")).
> 
> 

BTW, for chains of str_cpy(), a strscat() and a strcats() function 
should probably replace chained strcpy()s, so it would be something like:

l = strscpy(n, dest, src);
l = strscat(n - l, dest + l, src2);
l = strscat(n - l, dest + l, src3);
...
if (strcats(n - l, dest + l, srcN, NULL))
	goto handle_truncation_or_error;

And the user should make sure that srcN is not "" unless he doesn't care 
about truncation.  Otherwise, check at every step.

I'll send my source code for strscat and strcats, if strscpy and strcpys 
are considered for addition.


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/