From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4DEFC433EF for ; Thu, 3 Mar 2022 20:02:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF0678D0002; Thu, 3 Mar 2022 15:02:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E9FA88D0001; Thu, 3 Mar 2022 15:02:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D66D48D0002; Thu, 3 Mar 2022 15:02:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id C64B58D0001 for ; Thu, 3 Mar 2022 15:02:34 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 841F41820C784 for ; Thu, 3 Mar 2022 20:02:34 +0000 (UTC) X-FDA: 79204147428.27.7C8BC9C Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf27.hostedemail.com (Postfix) with ESMTP id F159B4000C for ; Thu, 3 Mar 2022 20:02:33 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id j15so10373843lfe.11 for ; Thu, 03 Mar 2022 12:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F++KWIByQw15zKEln3xtCXqdyRaB/5lOWU6i+7W/zvU=; b=PknX5RT2csG8YCPJJzeTThmKtWYz/gqBuB+ekT0aM3WjTZ3KKVFIpSIWfpfKVPM5Ki o+9YfSG9Yy7saDcQotbBnEVnPMoCo7IhS9uKplbQdtuhfSP4iQ1IBYoIUnm3uY7DHZq3 5Xjkqbv8O1UbcN/o1GM/kFCbUdwyb65CjJdIs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F++KWIByQw15zKEln3xtCXqdyRaB/5lOWU6i+7W/zvU=; b=Qaxt0LR7Vjr8rAHk8jPBQKSwCC3A9kCcx8ast0DklnaQXpg+70oiwvQ7gvkreILWdY y0UB/71TqgjpKrBSbWCDLgqfWQMtwh1B8JGu2mDV9Y5Z0F4OvhaH2wWvvAvOeLHbfkKn qxZuXwmqyREk4za6mp3qZFCNnvnJpedApYjQAAzgT9UogZTusL6qmIcIiFwgzji/284O y1gxhJ34hitrx+Kwxr/fy0mmzy1cNuoyaPDwZp5d4h3IRQfXYoXr/YcyBWQ240+T7i9b QWt/7U0lN6O3IYIyz5E6vlpGD7sXtE/TwL2xAxzuEXY+qrF0Rj9qITq80/m/Ce5bUdLc opWA== X-Gm-Message-State: AOAM531VDSDnqAUVUMHFLvJSAb/owgh+zeMH2JY8Hc/3qbHkv3MrRDQ2 Z1jS07bQqK72onMgN3R70SXTH0lz4XknUBRaXxc= X-Google-Smtp-Source: ABdhPJxKy4jSzHkB7I9vt9JEEXscRiTHWAswqJxE9OHD2jcirPZaua4JX80USWtTXab57HJlCgkZwA== X-Received: by 2002:a05:6512:3094:b0:442:ca74:a610 with SMTP id z20-20020a056512309400b00442ca74a610mr22090415lfd.438.1646337751916; Thu, 03 Mar 2022 12:02:31 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id h18-20020a05651c125200b0024607ecedfdsm656687ljh.128.2022.03.03.12.02.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Mar 2022 12:02:31 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id f37so10377409lfv.8 for ; Thu, 03 Mar 2022 12:02:31 -0800 (PST) X-Received: by 2002:a05:6512:6c6:b0:447:ca34:b157 with SMTP id u6-20020a05651206c600b00447ca34b157mr75483lff.435.1646337750887; Thu, 03 Mar 2022 12:02:30 -0800 (PST) MIME-Version: 1.0 References: <20220301075839.4156-1-xiam0nd.tong@gmail.com> <20220301075839.4156-3-xiam0nd.tong@gmail.com> In-Reply-To: <20220301075839.4156-3-xiam0nd.tong@gmail.com> From: Linus Torvalds Date: Thu, 3 Mar 2022 12:02:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] list: add new MACROs to make iterator invisiable outside the loop To: Xiaomeng Tong Cc: Arnd Bergmann , Jakob Koschel , Linux Kernel Mailing List , Greg Kroah-Hartman , Kees Cook , Jann Horn , Linux Kbuild mailing list , Linux-MM , Netdev Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: F159B4000C X-Stat-Signature: uip333b5as89gesgig4wmu9wqxfjy8pz Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PknX5RT2; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1646337753-172757 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 28, 2022 at 11:59 PM Xiaomeng Tong wrote: > > +#define list_for_each_entry_inside(pos, type, head, member) \ So as mentioned in another thread, I actually tried exactly this. And it was horrendous. It's _technically_ probably a very nice solution, but - it means that the already *good* cases are the ones that are penalized by having to change - the syntax of the thing becomes absolutely nasty which means that _practially_ it's exactly the wrong thing to do. Just as an example, this is a random current "good user" in kernel/exit.c: - list_for_each_entry_safe(p, n, dead, ptrace_entry) { + list_for_each_entry_safe_inside(p, n, struct task_struct, dead, ptrace_entry) { and while some of the effects are nice (no need to declare p/n ahead of time), just look at how nasty that line is. Basically every single use will result in an over-long line. The above example has minimal indentation, almost minimal variable names (to the point of not being very descriptive at all), and one of the most basic kernel structure types. And it still ended up 87 columns wide. And no, the answer to that is not "do it on multiple lines then". That is just even worse. So I really think this is a major step in the wrong direction. We should strive for the *bad* cases to have to do extra work, and even there we should really strive for legibility. Now, I think that "safe" version in particular can be simplified: there's no reason to give the "n" variable a name. Now that we can (with -stc=gnu11) just declare our own variables in the for-loop, the need for that externally visible 'next' declaration just goes away. So three of those 87 columns are pointless and should be removed. The macro can just internally decare 'n' like it always wanted (but couldn't do due to legacy C language syntax restrictions). But even with that fixed, it's still a very cumbersome line. Note how the old syntax was "only" 60 characters - long but still quite legible (and would have space for two more levels of indentation without even hitting 80 characters). And that was _despute_ having to have that 'n' declaration. And yes, the old syntax does require that struct task_struct *p, *n; line to declare the types, but that really is not a huge burden, and is not complicated. It's just another "variables of the right type" line (and as mentioned, the 'n' part has always been a C syntax annoyance). Linus