[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <635f1691-74e9-4e48-8ebf-8e7ce0c6d1e3@sirena.org.uk>
Date: Wed, 30 Oct 2024 17:14:48 +0000
From: Mark Brown <broonie@...nel.org>
To: Suraj Sonawane <surajsonawane0215@...il.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, linux-sound@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sound: fix uninit-value in i2s_dma_isr
On Wed, Oct 30, 2024 at 10:38:29PM +0530, Suraj Sonawane wrote:
> Fix an issue detected by the Smatch tool:
>
> sound/soc/bcm/bcm63xx-pcm-whistler.c:264 i2s_dma_isr()
> error: uninitialized symbol 'val_1'.
> sound/soc/bcm/bcm63xx-pcm-whistler.c:264 i2s_dma_isr()
> error: uninitialized symbol 'val_2'.
>
> These errors occurred because the variables 'val_1' and 'val_2' are
> declared but may not be assigned a value before they are used.
> Specifically, if the loop that assigns values to 'val_1' and 'val_2'
> does not execute (for example, when 'offlevel' is zero), these
> variables remain uninitialized, leading to potential undefined
> behavior.
>
> To resolve this issue, initialize 'val_1' and 'val_2' to 0 at the
> point of declaration. This ensures that 'val_1' and 'val_2' have
> defined values before they are used in subsequent calculations,
> preventing any warnings or undefined behavior in cases where the
> loop does not run.
This will shut the warning up, but why are these values valid? Are we
handling the cases where the loops do not execute properly?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists