All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: David Laight <david.laight.linux@gmail.com>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Daniel Lezcano <daniel.lezcano@kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Lukasz Luba <lukasz.luba@arm.com>
Subject: Re: [PATCH v1 1/1] thermal: sysfs: switch to use scnprintf() to suppress truncation warning
Date: Mon, 7 Sep 2026 07:21:30 +0300	[thread overview]
Message-ID: <ap47yiUB6oBihXiv@ashevche-desk.local> (raw)
In-Reply-To: <20260905105832.12192997@pumpkin>

On Sat, Sep 05, 2026 at 10:58:32AM +0100, David Laight wrote:
> On Mon, 17 Aug 2026 12:33:24 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > Switch the sysfs code to use scnprintf() to avoid warnings about potential
> > truncation of the names of the sysfs attributes.
> 
> It has to be a 'bug' that 'format overflow' warnings are generated for
> snprintf() but not for scnprintf().
> They really shouldn't behave differently.
> 
> I did some tests a while back and the warning goes away if you do
> 'some things' with the result (like comparing against the buffer size),
> but even explicitly ignoring it with a (void) cast isn't enough.
> 
> Using OPTIMIZER_HIDE_VAR() (or an _VAL variant) on the buffer size does
> stop the error, but I expect gcc to start checking sizeof(buf) as well.
> So both arguments might need hiding to get the warning ignored.

Yeah, but in a few subsystems (mostly visible in 'input') the technique of
using scnprintf() is used when either it's and ABI or we don't care about
possible truncation.

-- 
With Best Regards,
Andy Shevchenko



      reply	other threads:[~2026-09-07  4:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 10:33 [PATCH v1 1/1] thermal: sysfs: switch to use scnprintf() to suppress truncation warning Andy Shevchenko
2026-09-03 11:41 ` Andy Shevchenko
2026-09-04  8:01 ` Lukasz Luba
2026-09-04 13:54   ` Rafael J. Wysocki (Intel)
2026-09-05  9:58 ` David Laight
2026-09-07  4:21   ` Andy Shevchenko [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=ap47yiUB6oBihXiv@ashevche-desk.local \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=daniel.lezcano@kernel.org \
    --cc=david.laight.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.