Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Sun, 21 Aug 2022 23:40:18 +0200
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)
Message-ID: <YwKmQllm8Thr3scO@gmail.com>
References: <CAH2r5mtDFpaAWeGCtrfm_WPM6j-Gkt_O80=nKfp6y39aXaBr6w@mail.gmail.com>
 <CAHk-=wi+xbVq++uqW9YgWpHjyBHNB8a-xad+Xp23-B+eodLCEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wi+xbVq++uqW9YgWpHjyBHNB8a-xad+Xp23-B+eodLCEA@mail.gmail.com>
Precedence: bulk


* 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