From: Thorsten Blum <thorsten.blum@linux.dev>
To: Finn Thain <fthain@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>,
linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] m68k: mm: Remove size argument when calling strscpy()
Date: Fri, 7 Mar 2025 10:15:00 +0100 [thread overview]
Message-ID: <5216B227-6174-4C0A-9126-B8861473A0D3@linux.dev> (raw)
In-Reply-To: <e5e10808-5cca-243b-304f-4aa8db1d30b6@linux-m68k.org>
Hi Finn,
On 7. Mar 2025, at 00:24, Finn Thain wrote:
> On Thu, 6 Mar 2025, Geert Uytterhoeven wrote:
>> On Mon, 3 Mar 2025 at 00:07, Thorsten Blum wrote:
>>> The size parameter of strscpy() is optional and specifying the size of
>>> the destination buffer is unnecessary. Remove it to simplify the code.
>>>
>>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>>
>> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> i.e. will queue in the m68k tree for v6.15.
>>
> The commit message says "simplify the code" which is only true if you
> never scratch the surface (i.e. it's simple code if the reader is simple
> too...)
strscpy() automatically determines the length of the destination buffer
using sizeof() if the size argument is omitted. This makes the explicit
sizeof(m68k_command_line) unnecessary, so removing it shortens the code
without changing its behavior.
Both macro calls expand to the same code, and I find the shorter version
simpler to read (this doesn't mean that strscpy() itself is simple).
> Commit 30035e45753b ("string: provide strscpy()") was a good idea. It was
> easily auditable. But that's not what we have now.
>
> Patches like this one (which appear across the whole tree) need reviewers
> (lots of them) that know what kind of a bounds check you end up with when
> you ask an arbitary compiler to evaluate this:
>
> sizeof(dst) + __must_be_array(dst) + __must_be_cstr(dst) + __must_be_cstr(src)
>
> Frankly, I can't be sure. But it's a serious question, and not what I'd
> call a "simple" one.
I'm not sure I fully understand this part or how it's related to this
change. This patch doesn't change bounds checking, it just removes an
unnecessary macro argument.
Thanks,
Thorsten
next prev parent reply other threads:[~2025-03-07 9:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-02 23:05 Thorsten Blum
2025-03-06 17:41 ` Jean-Michel Hautbois
2025-03-06 17:44 ` Geert Uytterhoeven
2025-03-06 23:24 ` Finn Thain
2025-03-07 8:28 ` Geert Uytterhoeven
2025-03-07 8:58 ` Finn Thain
2025-03-07 9:28 ` Geert Uytterhoeven
2025-03-07 9:15 ` Thorsten Blum [this message]
2025-03-07 9:59 ` Finn Thain
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=5216B227-6174-4C0A-9126-B8861473A0D3@linux.dev \
--to=thorsten.blum@linux.dev \
--cc=fthain@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=jeanmichel.hautbois@yoseli.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.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 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®