You're right, I take that back. I said two negative values next to each other could make len equal to zero. I checked again, and that can't actually happen in either place that calls this code.
In the first place: there's a check just before the loop starts. If the next value is negative, the function stops right away and never reaches the loop. So the loop always has at least one real value to read.In the second place: the code clears part of the number right before checking it. That clearing always makes the check pass on the first try. So this loop also always runs at least once. So you're right — len can't actually reach zero through any existing code today. This isn't a bug that's currently happening. What's still true: the macro itself has no check for len <= 0. It only stays safe because both callers happen to prevent it from ever reaching zero. If either caller changes in the future, or a new caller is added without the same care, it would break. I'd like to keep this as a small safety check for the future, not as a fix for a bug happening today. If you think that's not worth adding, I'm fine dropping the patch. Thanks for pushing on this — I should have checked both callers fully before saying it was already happening. On Wed, 2 Sept 2026 at 17:55, Nam Cao <[email protected]> wrote: > Anshika Jain <[email protected]> writes: > > This is a latent bug: nothing in the current code prevents > > two adjacent negative values in an init_sequence from producing len=0, > > Can you elaborate what you mean by "two adjacent negative values in an > init_sequence from producing len=0"? How is it possible that negative > values in the init sequence causing len to be zero? > > > and there is no guarantee future or out-of-tree panel definitions > > won't do so. > > Basic testing of future drivers would prevent such bug. It is not on any > rarely-executed code path. > > Nam >
