From: Dan Carpenter <error27@gmail.com>
To: Rhys Tumelty <rhys@tumelty.co.uk>
Cc: gregkh@linuxfoundation.org,
Vaibhav Agarwal <vaibhav.sr@gmail.com>,
Mark Greer <mgreer@animalcreek.com>,
Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>,
greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: greybus: audio: fix snprintf truncation errors
Date: Sat, 6 Jun 2026 10:08:50 +0300 [thread overview]
Message-ID: <aiPHgttTk0bK563E@stanley.mountain> (raw)
In-Reply-To: <20260605192857.78944-1-rhys@tumelty.co.uk>
On Fri, Jun 05, 2026 at 08:28:56PM +0100, Rhys Tumelty wrote:
> change snprintf() to scnprintf() in both gbaudio_tplg_create_widget()
> and gbaudio_tplg_process_kcontrols() to prevent potential string
> truncation warnings when prefixing the device id to the control name.
>
This commit message is unclear. My understanding is that snprintf()
is complaining that the array size of w->name is less than the array
size of "GB %d %s" plus the array size of temp_name. This is a W=1
complaint.
I hate this warning. We use snprintf() to deliberately truncate
the string. Now it's complaining that the string might be truncated.
Oh no! What we want to happen might happen! This is the same argument
that people used to block safer alternatives to strcpy() into glibc
because "it's still going to truncate the string and that's equally
bad as a root exploit!"
First of all, the string is not going to be truncated. (I haven't
looked). Second of all, this warning makes no sense in the kernel.
I have never once had a bug which I failed to debug because the
last two bytes in a string were truncated. There has never been a
scenario where I was looking through dmesg and snprintf() truncated
some bytes so I couldn't guess what I was looking at.
So your solution is to change it to scnprintf() which is kernel only
and GCC doesn't know about it... I bet GCC eventually learns about
scnprintf() and it eventually becomes a warning again.
A better solution is to disable that annoying check.
regards,
dan carpenter
prev parent reply other threads:[~2026-06-06 7:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 19:28 [PATCH] staging: greybus: audio: fix snprintf truncation errors Rhys Tumelty
2026-06-06 7:08 ` Dan Carpenter [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=aiPHgttTk0bK563E@stanley.mountain \
--to=error27@gmail.com \
--cc=elder@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=greybus-dev@lists.linaro.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mgreer@animalcreek.com \
--cc=rhys@tumelty.co.uk \
--cc=vaibhav.sr@gmail.com \
/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