public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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
Subject: Re: [RFC] strcpys(): New function for copying strings safely
Date: Mon, 28 Jun 2021 14:00:17 +0200	[thread overview]
Message-ID: <d27912e6-f090-68af-295d-d40b00c1b0a7@gmail.com> (raw)
In-Reply-To: <52e57bd5-0d04-4b4f-978a-8c1dbc08115c@gmail.com>

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/

  reply	other threads:[~2021-06-28 12:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-27 19:26 Alejandro Colomar (man-pages)
2021-06-27 19:46 ` Alejandro Colomar (man-pages)
2021-06-28  8:15   ` David Laight
2021-06-28 11:32     ` Alejandro Colomar (man-pages)
2021-06-28 12:00       ` Alejandro Colomar (man-pages) [this message]
2021-06-28 12:10         ` Alejandro Colomar (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d27912e6-f090-68af-295d-d40b00c1b0a7@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=drepper@gmail.com \
    --cc=hch@lst.de \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tech@openbsd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).