Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1063925imm; Mon, 9 Jul 2018 16:31:23 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeaUk7qqot6hwxhEWdcffju7zQH6l7qKZVoHWBTIfCvZGDiXVv3FTToihMx/XgoPoQ6ggTQ X-Received: by 2002:a63:524e:: with SMTP id s14-v6mr19455617pgl.35.1531179083081; Mon, 09 Jul 2018 16:31:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531179083; cv=none; d=google.com; s=arc-20160816; b=M57Y3z+x8zHcS7bRC6ZWjPfm+MSFOkSEoPxQYPBtiBSGixwv99ytcZMqjhA3ZG7YeE mHVPMyVJZV8/ClMgXLS/micaziL/mol6JIZsd6RyYY9brzpsYi8hZh7hSLr6wGpDW6G5 Jnv10BOCS2neWOuYKVq2ez/ub5gwWoOGdcY0sv0CycRADYIZcvBe2o8XzhoW5tXTbH3u yOyLHEh3etr+amCo6hEUyyuB1wm6clPVyb1iPokHV2Ij4PfGTsswDpK7RKMvhMUxjq61 itVgAEV9nZ1AAkLvY3PKNELFwuo3CbKJJnAN6X5+USAKM1aj3eC4BwWzTMg2aD/HH/BO SLqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=X9Cm0uAqgf7RgcSiZ93Q4X8CtbB95te3dwPDznOcX7s=; b=VOirSxBOPwzWJUu2OBk83YU7fOOuJC8Mq7MIalkr0qx52qLyLY2HkNhDeILq/XDJlC hFX3CAZaS5tt3L+5TzCZIX32c9J0Nc3QjIpwa1rAIf87cvxyw2hhRQGtHmeQNTkdBx/s yMQ09JIS1Mw2UB+lKA8qMIRNiwXCq4rtmYHX6qYXevBrhLnh0wLw4wLL6OARHWusFYoc GSBZg4Q9u5Rxy44WtLJqepTCtQeEDEMnBhOMj5nBwH431JrtQ+8wmfkfM5RM6lfFOcYi 6CxipM6UvhdbGZWzbYCNVt7K5QHHOWzM/+IEdvc1F4KbUt/llBxBuQTOZcMpdAquxgoA CHjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w17-v6si15109243plq.221.2018.07.09.16.31.08; Mon, 09 Jul 2018 16:31:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933275AbeGIXaG (ORCPT + 99 others); Mon, 9 Jul 2018 19:30:06 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33832 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932847AbeGIXaF (ORCPT ); Mon, 9 Jul 2018 19:30:05 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.92]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id C7753E2E; Mon, 9 Jul 2018 23:30:03 +0000 (UTC) Date: Mon, 9 Jul 2018 16:30:01 -0700 From: Andrew Morton To: Daniel Vetter Cc: LKML , DRI Development , Intel Graphics Development , Gustavo Padovan , Maarten Lankhorst , Sean Paul , David Airlie , Kees Cook , Ingo Molnar , Greg Kroah-Hartman , NeilBrown , Wei Wang , Stefan Agner , Andrei Vagin , Randy Dunlap , Andy Shevchenko , Yisheng Xie , Peter Zijlstra , Daniel Vetter Subject: Re: [PATCH] kernel.h: Add for_each_if() Message-Id: <20180709163001.8fb8148223a57bc46a13fbda@linux-foundation.org> In-Reply-To: <20180709162509.29343-1-daniel.vetter@ffwll.ch> References: <20180709083650.23549-1-daniel.vetter@ffwll.ch> <20180709162509.29343-1-daniel.vetter@ffwll.ch> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter wrote: > To avoid compilers complainig about ambigious else blocks when putting > an if condition into a for_each macro one needs to invert the > condition and add a dummy else. We have a nice little convenience > macro for that in drm headers, let's move it out. Subsequent patches > will roll it out to other places. > > The issue the compilers complain about are nested if with an else > block and no {} to disambiguate which if the else belongs to. The C > standard is clear, but in practice people forget: > > if (foo) > if (bar) > /* something */ > else > /* something else um, yeah, don't do that. Kernel coding style is very much to do if (foo) { if (bar) /* something */ else /* something else } And if not doing that generates a warning then, well, do that. > The same can happen in a for_each macro when it also contains an if > condition at the end, except the compiler message is now really > confusing since there's only 1 if: > > for_each_something() > if (bar) > /* something */ > else > /* something else > > The for_each_if() macro, by inverting the condition and adding an > else, avoids the compiler warning. Ditto. > Motivated by a discussion with Andy and Yisheng, who want to add > another for_each_macro which would benefit from for_each_if() instead > of hand-rolling it. Ditto. > v2: Explain a bit better what this is good for, after the discussion > with Peter Z. Presumably the above was discussed in whatever-thread-that-was.