All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: "'Alejandro Colomar (man-pages)'" <alx.manpages@gmail.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>
Subject: RE: [RFC] strcpys(): New function for copying strings safely
Date: Mon, 28 Jun 2021 08:15:38 +0000	[thread overview]
Message-ID: <f5bfab0dce604736b6a563a4f9f7ce43@AcuMS.aculab.com> (raw)
In-Reply-To: <38428d5e-ead2-bf18-e198-cecd4caeb3e7@gmail.com>

From: Alejandro Colomar
> Sent: 27 June 2021 20:47
> 
> On 6/27/21 9:26 PM, Alejandro Colomar (man-pages) wrote:
> >
> > It is designed so that usage requires the minimum number of lines of
> > code for complete usage (including error handling checks):
> >
> > [[
> > // When we already checked that 'size' is >= 1
> > // and truncation is not an issue:
> >
> > strcpys_np(size, dest, src, NULL);
> 
> Also, given how unlikely this case is, I have in my code:
> `[[gnu::warn_unused_result]]`

warn_unused_result is such a PITA it should never have been invented.
At least no one seems to have been stupid enough to apply it to fprintf()
(you need to do fflush() before looking for errors).

In most cases strcpy() is safe - but if the inputs are 'corrupt'
horrid things happen - so you need truncation for safety.
But you really may not care whether the data got truncated.

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.

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.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2021-06-28  8:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-27 19:26 [RFC] strcpys(): New function for copying strings safely Alejandro Colomar (man-pages)
2021-06-27 19:46 ` Alejandro Colomar (man-pages)
2021-06-28  8:15   ` David Laight [this message]
2021-06-28 11:32     ` Alejandro Colomar (man-pages)
2021-06-28 12:00       ` Alejandro Colomar (man-pages)
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=f5bfab0dce604736b6a563a4f9f7ce43@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=alx.manpages@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.