[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Mar 2022 16:30:07 +0800
From: Xiaomeng Tong <xiam0nd.tong@...il.com>
To: jakobkoschel@...il.com
Cc: David.Laight@...LAB.COM, akpm@...ux-foundation.org,
alsa-devel@...a-project.org, amd-gfx@...ts.freedesktop.org,
andriy.shevchenko@...ux.intel.com, arnd@...db.de,
bcm-kernel-feedback-list@...adcom.com, bjohannesmeyer@...il.com,
c.giuffrida@...nl, christian.koenig@....com,
christophe.jaillet@...adoo.fr, dan.carpenter@...cle.com,
dmaengine@...r.kernel.org, drbd-dev@...ts.linbit.com,
dri-devel@...ts.freedesktop.org, gustavo@...eddedor.com,
h.j.bos@...nl, intel-gfx@...ts.freedesktop.org,
intel-wired-lan@...ts.osuosl.org, jgg@...pe.ca,
keescook@...omium.org, kgdb-bugreport@...ts.sourceforge.net,
kvm@...r.kernel.org, linux-arch@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-aspeed@...ts.ozlabs.org, linux-block@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net,
linux-fsdevel@...r.kernel.org, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
linux-mediatek@...ts.infradead.org, linux-pm@...r.kernel.org,
linux-rdma@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-sgx@...r.kernel.org, linux-staging@...ts.linux.dev,
linux-tegra@...r.kernel.org, linux-usb@...r.kernel.org,
linux-wireless@...r.kernel.org,
linux1394-devel@...ts.sourceforge.net, linux@...musvillemoes.dk,
linuxppc-dev@...ts.ozlabs.org, nathan@...nel.org,
netdev@...r.kernel.org, nouveau@...ts.freedesktop.org,
rppt@...nel.org, samba-technical@...ts.samba.org,
tglx@...utronix.de, tipc-discussion@...ts.sourceforge.net,
torvalds@...ux-foundation.org,
v9fs-developer@...ts.sourceforge.net, xiam0nd.tong@...il.com
Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
> I think this would make sense, it would mean you only assign the containing
> element on valid elements.
>
> I was thinking something along the lines of:
>
> #define list_for_each_entry(pos, head, member) \
> for (struct list_head *list = head->next, typeof(pos) pos; \
> list == head ? 0 : (( pos = list_entry(pos, list, member), 1)); \
> list = list->next)
>
> Although the initialization block of the for loop is not valid C, I'm
> not sure there is any way to declare two variables of a different type
> in the initialization part of the loop.
It can be done using a *nested loop*, like this:
#define list_for_each_entry(pos, head, member) \
for (struct list_head *list = head->next, cond = (struct list_head *)-1; cond == (struct list_head *)-1; cond = NULL) \
for (typeof(pos) pos; \
list == head ? 0 : (( pos = list_entry(pos, list, member), 1)); \
list = list->next)
>
> I believe all this does is get rid of the &pos->member == (head) check
> to terminate the list.
Indeed, although the original way is harmless.
> It alone will not fix any of the other issues that using the iterator
> variable after the loop currently has.
Yes, but I stick with the list_for_each_entry_inside(pos, type, head, member)
way to make the iterator invisiable outside the loop (before and after the loop).
It is maintainable longer-term than "type(pos) pos" one and perfect.
see my explain:
https://lore.kernel.org/lkml/20220302093106.8402-1-xiam0nd.tong@gmail.com/
and list_for_each_entry_inside(pos, type, head, member) patch here:
https://lore.kernel.org/lkml/20220301075839.4156-3-xiam0nd.tong@gmail.com/
--
Xiaomeng Tong
Powered by blists - more mailing lists