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.
prev parent 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®