mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/arm64: Prevent build warnings from -Wmaybe-uninitialized
Date: Fri, 27 Jun 2025 11:55:34 +0100	[thread overview]
Message-ID: <aF54phWq1IGlaphz@finisterre.sirena.org.uk> (raw)
In-Reply-To: <af5cbd48-6312-481d-8e91-7739612493c1@arm.com>

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

On Fri, Jun 27, 2025 at 04:15:09PM +0530, Anshuman Khandual wrote:
> On 25/06/25 3:54 PM, Mark Brown wrote:

> >> -	int status;
> >> +	int status = 0;

> > This will shut the warnings up, but it's a bit of a heavy hammer that
> > means that the warning can never trigger warnings for that variable
> > being unused.  Is it possible to fix this by updating the control flow
> > such that the compiler can tell that the initialisation follows the use?

> The problem might not exist in reality. In the test function test_fork()
> in the file tools/testing/selftests/arm64/gcs/basic-gcs.c there does not
> seem to be a path where WIFEXITED(status) might get called when 'status'
> has not been initialized as there is a preceding waitpid() which would
> ensure 'status' gets set. Similar scenarios are present in fork_test_c()
> and write_fork_read() as well. 

Yes, it's a fairly common false positive pattern (in this case it'll be
that the compiler can't understand the constraints with pulling things
out of the exit status).

> But the compiler still throws these build warnings. Seems to be false
> positives and this fix just works around that.

Right, the problem is that it works around it with a big hammer that
just shuts the warning up completely meaning that if we do cause issues
in the future then the compiler won't be able to tell us about them.  It
would be better to suppess it by changing the control flow such that the
compiler can follow it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2025-06-27 10:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-25  2:01 Anshuman Khandual
2025-06-25 10:24 ` Mark Brown
2025-06-27 10:45   ` Anshuman Khandual
2025-06-27 10:55     ` Mark Brown [this message]
2025-07-07 13:10 ` Thomas Weißschuh

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=aF54phWq1IGlaphz@finisterre.sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=will@kernel.org \
    /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

all inboxes | Powered by JetHome®