lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 6 Mar 2022 10:57:15 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Jakob Koschel <jakobkoschel@...il.com> Cc: Xiaomeng Tong <xiam0nd.tong@...il.com>, Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jann Horn <jannh@...gle.com>, Kees Cook <keescook@...omium.org>, Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>, Netdev <netdev@...r.kernel.org> Subject: Re: [PATCH 2/6] list: add new MACROs to make iterator invisiable outside the loop On Sun, Mar 6, 2022 at 4:19 AM Jakob Koschel <jakobkoschel@...il.com> wrote: > > I guess we could apply this to list_for_each_entry() as well > once all the uses after the loop are fixed? I think that would be a good longer-term plan. "list_traverse()" ends up being simpler syntactically, and has a certain level of inherent type safety (not just the "don't expose the mis-typed head pointer after the loop"). > I feel like this simply introduces a new set of macros > (we would also need list_traverse_reverse(), list_traverse_continue_reverse() > etc) and end up with a second set of macros that do pretty much > the same as the first one. I think that if we're happy with this, we can probably do a scripted conversion. But I do like how it's incremental, in that we wouldn't necessarily have to do it all in one go. Because it's always really painful with flag-day interface changes, which it would be to actually change the semantics of "list_for_each_entry()" without a name change. It just makes for a lot of pain for things that aren't in-tree yet (not just drivers that are out-of-tree in general, but drivers in development etc). And I really disliked the "pass the type to the list_for_each()" macro, because of how it made the end result look more complex. But list_traverse() looks like it would make the end result better both from a user perspective (ie the code just looks simpler) but also from the type safety point. > Personally I guess I also prefer the name list_for_each_entry() over list_traverse() > and not having two types of iterators for the same thing at the same time. I absolutely agree with you in theory, and in many ways I like list_for_each_entry() better as a name too (probably just because I'm used to it). But keeping the same name and changing how it works ends up being such a "everything at once" thing that I don't think it's realistic. Linus
Powered by blists - more mailing lists