On Thu, Oct 31, 2024 at 12:17:56PM +0530, Suraj Sonawane wrote:Thank you for clarifying.
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?