Re: [PATCH] sound: fix uninit-value in i2s_dma_isr

[Mark Brown <broonie@xxxxxxxxxx>]

On Thu, Oct 31, 2024 at 12:17:56PM +0530, Suraj Sonawane wrote:
> On 30/10/24 22:44, Mark Brown wrote:

> > This will shut the warning up, but why are these values valid?  Are we
> > handling the cases where the loops do not execute properly?

> Thank you for the feedback and your time.

> The uninitialized warning for val_1 and val_2 arises because, in some cases,
> the offlevel value is zero, and as a result, the loop does not execute,
> leaving these variables potentially undefined. The subsequent code
> calculates prtd->dma_addr_next using val_1 + val_2, so it's necessary to
> have val_1 and val_2 initialized to a known value, even when the loop does
> not run.

> Initializing them to zero ensures prtd->dma_addr_next has a defined value
> without triggering undefined behavior. However, if a zero initialization
> could cause unintended behavior in dma_addr_next, I could alternatively
> handle this case by setting dma_addr_next conditionally when offlevel is
> non-zero.

This is describing again what the patch does, which basically just boils
down to shutting up the warning.

> Let me know if there’s a preferred approach, or if you'd suggest a different
> initial value for these variables based on the expected use.

We need to understand what the change is doing - what do the values
mean, is the real issue that we're missing some error handling for the
case that lets us fall through without initialisation?

Attachment: signature.asc
Description: PGP signature