From: Thierry Reding <thierry.reding@kernel.org>
To: Artem Lytkin <iprintercanon@gmail.com>
Cc: linux-staging@lists.linux.dev, gregkh@linuxfoundation.org,
marvin24@gmx.de, linux-tegra@vger.kernel.org
Subject: Re: [PATCH RESEND] staging: nvec: use strcmp() instead of strncmp() with magic length
Date: Mon, 27 Jul 2026 17:58:20 +0200 [thread overview]
Message-ID: <amd-EkmT_H1xlm7Q@orome> (raw)
In-Reply-To: <20260723161823.23921-1-iprintercanon@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
On Thu, Jul 23, 2026 at 07:18:23PM +0300, Artem Lytkin wrote:
> Replace strncmp() with a hardcoded length of 30 with strcmp().
> The bat_type string is already null-terminated (set two lines above),
> so strncmp() with an arbitrary length is misleading and functionally
> equivalent to strcmp().
>
> Signed-off-by: Artem Lytkin <iprintercanon@gmail.com>
> ---
> drivers/staging/nvec/nvec_power.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I don't really see a point in this. strncmp() doesn't do any harm and it
isn't misleading either. It's just very explicit that it should never
check more than those 30 characters that can fit into the type string.
Technically res->length could be larger than 30, in which case the
memcpy() might copy more than those 30. Judging by the nvec core code we
never sanity check the length, so even that memcpy() could be entirely
wrong.
Either way, this change by itself doesn't look useful.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-07-27 15:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 16:18 [PATCH RESEND] staging: nvec: use strcmp() instead of strncmp() with magic length Artem Lytkin
2026-07-27 15:58 ` Thierry Reding [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=amd-EkmT_H1xlm7Q@orome \
--to=thierry.reding@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=iprintercanon@gmail.com \
--cc=linux-staging@lists.linux.dev \
--cc=linux-tegra@vger.kernel.org \
--cc=marvin24@gmx.de \
/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