mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Thorsten Blum <thorsten.blum@linux.dev>,
	Don Brace <don.brace@microchip.com>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-hardening@vger.kernel.org, storagedev@microchip.com,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: hpsa: Replace deprecated strncpy() with strscpy()
Date: Thu, 13 Feb 2025 09:34:38 -0800	[thread overview]
Message-ID: <51c6b704-7dd0-4d2c-acae-8ba427d57070@acm.org> (raw)
In-Reply-To: <34BB4FDE-062D-4C1B-B246-86CB55F631B8@linux.dev>

On 2/13/25 3:24 AM, Thorsten Blum wrote:
> This subtle difference between strncpy() and strscpy() regarding the
> number of bytes copied isn't really documented anywhere, is it? The
> documentation I came across so far seems to focus mostly on the
> different return values of the two functions.

 From the description of commit 9022ed0e7e65 ("strscpy: write destination
buffer only once"):

     So strscpy not only guarantees NUL-termination (unlike strncpy), it 
also
     doesn't do unnecessary padding at the destination.  But at the same 
time
     also avoids byte-at-a-time reads and writes by _allowing_ some 
extra NUL
     writes - within the size, of course - so that the whole copy can be 
done
     with word operations.

     It is also stable in the face of a mutable source string: it explicitly
     does not read the source buffer multiple times (so an implementation
     using "strnlen()+memcpy()" would be wrong), and does not read the 
source
     buffer past the size (like the mis-design that is strlcpy does).

     Finally, the return value is designed to be simple and unambiguous: if
     the string cannot be copied fully, it returns an actual negative error,
     making error handling clearer and simpler (and the caller already knows
     the size of the buffer).  Otherwise it returns the string length of the
     result.

More information is available in the description of commit 30c44659f4a3
("Merge branch 'strscpy' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile").

Thanks,

Bart.


      reply	other threads:[~2025-02-13 17:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-12 22:22 Thorsten Blum
2025-02-13 11:24 ` Thorsten Blum
2025-02-13 17:34   ` Bart Van Assche [this message]

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=51c6b704-7dd0-4d2c-acae-8ba427d57070@acm.org \
    --to=bvanassche@acm.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=don.brace@microchip.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=storagedev@microchip.com \
    --cc=thorsten.blum@linux.dev \
    /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

all inboxes | Powered by JetHome®