From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steve French <smfrench@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
CIFS <linux-cifs@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>
Subject: Re: strlcpy() notes (was Re: [GIT PULL] smb3 client fixes)
Date: Sun, 21 Aug 2022 23:40:18 +0200 [thread overview]
Message-ID: <YwKmQllm8Thr3scO@gmail.com> (raw)
In-Reply-To: <CAHk-=wi+xbVq++uqW9YgWpHjyBHNB8a-xad+Xp23-B+eodLCEA@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> So I despise strlcpy(), but I think strscpy() is kind of broken too.
> For the generic case, it really should have two separate buffer sizes.
>
> (2) if you expect the destination buffer contents to be untouched
> past the terminating NUL character, you're simply out of luck
>
> The strscpy() assumption is that it can arbitrarily write to the
> destination buffer.
>
> So the best way to think of "strscpy()" is really as a "optimized
> memcpy for strings". That's almost exactly how it acts. It will do a
> memcpy(), but stop when it notices that it has copied a NUL character.
Not to shed-paint this too much, but would it help if the naming reflected
that property of chunk-size NUL-(over)write a bit better?
- memcpy_str(), memstrcpy(), memscpy(), etc.?
Developers do tend to think differently about operations that are named
after memcpy(). Here the argument order and semantics are pretty close to
memcpy() - if the naming is similar, we'd want people to think of it as a
memcpy(), not a string-copy.
[ Personally I'd prefer memcpy_str(): it's a variant of memcpy() that stops
earlier if possible, and does the 'early stop' safely & robustly. ]
Thanks,
Ingo
next prev parent reply other threads:[~2022-08-21 21:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-20 22:34 [GIT PULL] smb3 client fixes Steve French
2022-08-21 18:13 ` strlcpy() notes (was Re: [GIT PULL] smb3 client fixes) Linus Torvalds
2022-08-21 21:40 ` Ingo Molnar [this message]
2022-08-23 8:56 ` Catalin Marinas
2022-08-23 17:37 ` Linus Torvalds
2022-08-24 22:02 ` Catalin Marinas
2022-08-26 7:40 ` Rasmus Villemoes
2022-08-21 18:42 ` [GIT PULL] smb3 client fixes pr-tracker-bot
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=YwKmQllm8Thr3scO@gmail.com \
--to=mingo@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smfrench@gmail.com \
--cc=torvalds@linux-foundation.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.