Received-SPF: pass (google.com: domain of linux-kernel+bounces-80597-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848
Precedence: bulk
MIME-Version: 1.0
Message-Id: <bfc0de42-a34b-4701-a392-6cbd0061a433@app.fastmail.com>
In-Reply-To: <20240225121929.2e3fdc1b@jic23-huawei>
References: <20240224121140.1883201-1-arnd@kernel.org>
 <20240225121929.2e3fdc1b@jic23-huawei>
Date: Mon, 26 Feb 2024 07:40:18 +0100
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Jonathan Cameron" <jic23@kernel.org>, "Arnd Bergmann" <arnd@kernel.org>
Cc: "Lars-Peter Clausen" <lars@metafoo.de>,
 "Nathan Chancellor" <nathan@kernel.org>,
 "Nick Desaulniers" <ndesaulniers@google.com>,
 "Bill Wendling" <morbo@google.com>, "Justin Stitt" <justinstitt@google.com>,
 =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>,
 linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] iio: avoid fortify-string overflow error
Content-Type: text/plain

On Sun, Feb 25, 2024, at 13:19, Jonathan Cameron wrote:
> On Sat, 24 Feb 2024 13:11:34 +0100 Arnd Bergmann <arnd@kernel.org> wrote:
> It's a false positive, but the compiler has no way to tell that only bits
> 0 and 1 can be set.
> https://lore.kernel.org/linux-iio/20240222222335.work.759-kees@kernel.org/
> for discussion on why + the missing zero initialization bug Kees noticed whilst
> looking at this code.
>
> Kees proposed an alternative way to suppress the warning that I've just applied.
> https://lore.kernel.org/linux-iio/20240223172936.it.875-kees@kernel.org/

Right, that's fine.

> Your solution also works but leaves the implication of a real path to
> overflow the buffer when there isn't one, hence I prefer what Kees had unless
> some future version of clang trips over that in which case we can revisit.

The idea with my patch was to make it obvious to the compiler
that there can't be an overflow, which would ensure the warning
doesn't come back. Kees' version works by avoiding whatever
code path in the compiler trips over the warning, but it's more
likely to come back later if something changes in the compiler
itself, so there is a slight chance that we have it work
around it again.

      Arnd