linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Metcalf <cmetcalf@ezchip.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Fabian Frederick <fabf@skynet.be>,
	Randy Dunlap <rdunlap@infradead.org>,
	Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>,
	<gregkh@linuxfoundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"David S. Miller" <davem@davemloft.net>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Grant Likely <grant.likely@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	<linux-arch@vger.kernel.org>
Subject: Re: [PATCH 2/3] string: provide strscpy() and strscpy_truncate()
Date: Wed, 6 May 2015 11:21:05 -0400	[thread overview]
Message-ID: <554A3161.3030609@ezchip.com> (raw)
In-Reply-To: <20150506150140.GB12986@mwanda>

On 5/6/2015 11:01 AM, Dan Carpenter wrote:
> On Thu, Apr 30, 2015 at 12:01:16PM -0400, Chris Metcalf wrote:
>> >+ssize_t strscpy(char *dest, const char *src, size_t count)
>> >+{
>> >+	ssize_t res = strscpy_truncate(dest, src, count);
>> >+	if (res < 0 && count != 0)
>> >+		dest[0] = '\0';
> How is this better than returning a truncated string?  Is it just
> because the caller was naughty so we give them a spanking?

There are basically two issues here:

1. A truncated string with an error return may still cause program errors,
even if the caller checks for the error return, if the buffer is later interpreted
as a valid string due to some other program error.  It's defensive programming.

2. Programmers are fond of ignoring error returns.  My experience with
truncated strings is that in too many cases, truncation causes program
errors down the line.  It's better to ensure that no partial string is returned
in this case.

In a perfect world, all error returns would be checked, and there would be
no need for this, but we definitely don't live in that world :-)

That said, although I think my approach is correct, I'm open to a consensus
that having strscpy() leave a truncated string in the dest buffer is better.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com


  reply	other threads:[~2015-05-06 15:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28  3:48 revert "fs/befs/linuxvfs.c: replace strncpy by strlcpy" Al Viro
2015-04-28  5:35 ` Fabian Frederick
2015-04-28 16:05   ` Al Viro
2015-04-28 16:42     ` Fabian Frederick
2015-04-28 17:39       ` Al Viro
2015-04-28 20:16         ` Fabian Frederick
2015-04-28 16:42     ` Linus Torvalds
2015-04-28 19:48       ` Chris Metcalf
2015-04-28 20:51         ` Linus Torvalds
2015-04-28 21:38           ` Chris Metcalf
2015-04-28 21:48             ` Linus Torvalds
2015-04-29  0:35               ` Al Viro
2015-04-29  8:24                 ` Geert Uytterhoeven
2015-04-30 16:01               ` [PATCH 0/3] add new strscpy() API for string copy Chris Metcalf
2015-04-30 16:01                 ` [PATCH 1/3] Make asm/word-at-a-time.h available on all architectures Chris Metcalf
2015-04-30 16:01                 ` [PATCH 2/3] string: provide strscpy() and strscpy_truncate() Chris Metcalf
2015-05-06 15:01                   ` Dan Carpenter
2015-05-06 15:21                     ` Chris Metcalf [this message]
2015-05-06 15:59                       ` Dan Carpenter
2015-05-06 16:45                         ` Geert Uytterhoeven
2015-05-07  9:00                           ` Dan Carpenter
2015-05-07 15:10                             ` Chris Metcalf
2015-04-30 16:01                 ` [PATCH 3/3] tile: use global strscpy() rather than private copy Chris Metcalf
2015-05-11 15:37                 ` [PATCH 0/3] add new strscpy() API for string copy Chris Metcalf
2015-05-14 23:10                 ` Michael Ellerman
2015-05-15 15:15                   ` Chris Metcalf
2015-05-18  1:13                     ` Michael Ellerman
2015-05-26 19:33                       ` Chris Metcalf
  -- strict thread matches above, loose matches on Subject: below --
2015-06-30 18:01 [GIT PULL] strscpy string copy function Chris Metcalf
2015-07-01 16:11 ` Linus Torvalds
2015-07-08 20:20   ` [PATCH v2 0/3] add new strscpy() API for string copy Chris Metcalf
2015-07-08 20:20     ` [PATCH v2 1/3] Make asm/word-at-a-time.h available on all architectures Chris Metcalf
2015-07-08 20:20     ` [PATCH v2 2/3] string: provide strscpy() Chris Metcalf
2015-07-08 20:54       ` Geert Uytterhoeven
2015-07-08 20:20     ` [PATCH v2 3/3] tile: use global strscpy() rather than private copy Chris Metcalf

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=554A3161.3030609@ezchip.com \
    --to=cmetcalf@ezchip.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@oracle.com \
    --cc=davem@davemloft.net \
    --cc=fabf@skynet.be \
    --cc=fweisbec@gmail.com \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rickard_strandqvist@spectrumdigital.se \
    --cc=sam@ravnborg.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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 NNTP newsgroup(s).