public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eli Billauer <eli.billauer@gmail.com>
To: Thorsten Blum <thorsten.blum@linux.dev>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] char: xillybus: use strscpy() in init_chrdev
Date: Tue, 28 Apr 2026 11:05:11 +0200	[thread overview]
Message-ID: <d8e58eb2-5495-c3dd-659d-2e592d1aa7bf@outbound.gmail.com> (raw)
In-Reply-To: <afB2H9bRH2fAr9vc@linux.dev>

On 28/04/2026 10:55, Thorsten Blum wrote:
>> And even though it's formally OK to use strscpy() with two arguments, and
>> let the compilation machinery find out the length of the char array, I have
>> to admit that it gives me the chills. Buffer overflow and that.
> You probably mean strcpy()? strscpy() is safe regarding buffer overflow.

I meant strscpy(). We agree that it's formally safe to use, but I get a 
really bad feeling with not having the length of the buffer explicitly 
written out in the function call.

One could argue that it's better to let the machine figure out the 
length of the buffer instead of using UNITNAMELEN (because I'm a human 
and I can err), but in this specific case, UNITNAMELEN is relied upon 
anyhow a few rows later.

This is all about coding style. The main point is that I see this patch 
as a negligible optimization in CPU cycles coming with a slight 
obfuscation of the code's readability. A bit of "if it ain't broke, 
don't fix it".

Regards,
    Eli

      reply	other threads:[~2026-04-28  9:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27 17:37 [PATCH] char: xillybus: use strscpy() in init_chrdev Thorsten Blum
2026-04-28  8:37 ` Eli Billauer
2026-04-28  8:55   ` Thorsten Blum
2026-04-28  9:05     ` Eli Billauer [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=d8e58eb2-5495-c3dd-659d-2e592d1aa7bf@outbound.gmail.com \
    --to=eli.billauer@gmail.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thorsten.blum@linux.dev \
    /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