From: Christoph Hellwig <hch@lst.de>
To: Justin Stitt <justinstitt@google.com>
Cc: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org, ksummit@lists.linux.dev
Subject: the nul-terminated string helper desk chair rearrangement, was: Re: [PATCH] nvme-fabrics: replace deprecated strncpy with strscpy
Date: Thu, 19 Oct 2023 07:46:42 +0200 [thread overview]
Message-ID: <20231019054642.GF14346@lst.de> (raw)
In-Reply-To: <20231018-strncpy-drivers-nvme-host-fabrics-c-v1-1-b6677df40a35@google.com>
On Wed, Oct 18, 2023 at 10:48:49PM +0000, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
If we want that we need to stop pretendening direct manipulation of
nul-terminate strings is a good idea. I suspect the churn of replacing
one helper with another, maybe slightly better, one probably
introduces more bugs than it fixes.
If we want to attack the issue for real we need to use something
better.
lib/seq_buf.c is a good start for a lot of simple cases that just
append to strings including creating complex ones. Kent had a bunch
of good ideas on how to improve it, but couldn't be convinced to
contribute to it instead of duplicating the functionality which
is a bit sad, but I think we need to switch to something like
seq_buf that actually has a counted string instead of all this messing
around with the null-terminated strings.
next parent reply other threads:[~2023-10-19 5:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231018-strncpy-drivers-nvme-host-fabrics-c-v1-1-b6677df40a35@google.com>
2023-10-19 5:46 ` Christoph Hellwig [this message]
2023-10-19 6:01 ` the nul-terminated string helper desk chair rearrangement Kees Cook
2023-10-19 7:01 ` Willy Tarreau
2023-10-19 11:40 ` Alexey Dobriyan
2023-10-19 12:00 ` Willy Tarreau
2023-10-20 4:46 ` Christoph Hellwig
2023-10-20 17:40 ` Justin Stitt
2023-10-20 17:56 ` Linus Torvalds
2023-10-20 18:22 ` Kees Cook
2023-10-20 18:30 ` Kees Cook
2023-10-26 10:01 ` Christoph Hellwig
2023-10-26 11:39 ` James Bottomley
2023-10-26 13:52 ` Steven Rostedt
2023-10-26 13:59 ` Geert Uytterhoeven
2023-10-27 18:32 ` Alexey Dobriyan
2023-10-26 14:05 ` Jonathan Corbet
2023-10-27 7:08 ` Kalle Valo
2023-10-26 13:44 ` Andrew Lunn
2023-10-26 13:51 ` Laurent Pinchart
2023-10-26 14:27 ` James Bottomley
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=20231019054642.GF14346@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=justinstitt@google.com \
--cc=kbusch@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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).