On Mon, Feb 28, 2022 at 05:28:58PM -0500, James Bottomley wrote:
On Mon, 2022-02-28 at 23:59 +0200, Mike Rapoport wrote:
On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley < James.Bottomley@HansenPartnership.com> wrote:
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
[...]
I do wish we could actually poison the 'pos' value after the loop somehow - but clearly the "might be uninitialized" I was hoping for isn't the way to do it.
Anybody have any ideas?
I think we should look at the use cases why code is touching (pos) after the loop.
Just from skimming over the patches to change this and experience with the drivers/subsystems I help to maintain I think the primary pattern looks something like this:
list_for_each_entry(entry, head, member) { if (some_condition_checking(entry)) break; } do_something_with(entry);
Actually, we usually have a check to see if the loop found anything, but in that case it should something like
if (list_entry_is_head(entry, head, member)) { return with error; } do_somethin_with(entry);
Suffice? The list_entry_is_head() macro is designed to cope with the bogus entry on head problem.
Won't suffice because the end goal of this work is to limit scope of entry only to loop. Hence the need for additional variable.
Well, yes, but my objection is more to the size of churn than the desire to do loop local. I'm not even sure loop local is possible, because it's always annoyed me that for (int i = 0; ... in C++ defines i in the outer scope not the loop scope, which is why I never use it.
In C its scope is the rest of the declaration and the entire loop, not anything after it. This was the same in C++98 already, btw (but in pre-standard versions of C++ things were like you remember, yes, and it was painful).
Segher