[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9149f9c75c9f961da29829577ba4476681f4e82c.camel@baylibre.com>
Date: Tue, 20 Jan 2026 11:03:26 +0100
From: Francesco Lavra <flavra@...libre.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Lorenzo Bianconi <lorenzo@...nel.org>, Jonathan Cameron
<jic23@...nel.org>, David Lechner <dlechner@...libre.com>, Nuno
Sá <nuno.sa@...log.com>, Andy Shevchenko
<andy@...nel.org>, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] iio: imu: st_lsm6dsx: add support for rotation
sensor
On Tue, 2026-01-20 at 11:36 +0200, Andy Shevchenko wrote:
> On Tue, Jan 20, 2026 at 10:28:15AM +0100, Francesco Lavra wrote:
> > On Mon, 2026-01-19 at 12:33 +0200, Andy Shevchenko wrote:
> > > On Mon, Jan 19, 2026 at 11:04:49AM +0100, Francesco Lavra wrote:
>
> ...
>
> > > > + snprintf(sensor->name, sizeof(sensor->name), "%s_sf",
> > > > name);
> > >
> > > Does GCC complain on this (`make W=1` build)?
> > > Since this can cut the string and we don't check the return value,
> > > the Q
> > > is:
> > > is this okay to have a reduced string?
> >
> > gcc does not complain with W=1. sensor->name is appropriately sized to
> > accommodate the longest possible name; if it wasn't, the string would
> > be
> > cut in the accel and gyro IIO devices too (which use a longer suffix
> > than
> > "_sf").
>
> Right, the question is if compiler can prove that or not.
>
> We have several patches in input subsystem to hide the warning by
> switching
> to scnprintf(), which I consider not the best approach, but still it
> depends
> if we care about cut or not. If we do, we should check for overflow.
A truncated string would result in a corrupted value in
/sys/bus/iio/devices/iio:deviceX/name, so I would say we do care if it's
truncated. But I think the most appropriate check we could add in the code
is a BUG_ON(); would that be acceptable?
Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)
Powered by blists - more mailing lists