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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1960EC433FE for ; Mon, 28 Feb 2022 21:13:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230090AbiB1VNy (ORCPT ); Mon, 28 Feb 2022 16:13:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230084AbiB1VNu (ORCPT ); Mon, 28 Feb 2022 16:13:50 -0500 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0A2D5ECB1A; Mon, 28 Feb 2022 13:12:56 -0800 (PST) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 21SKr95E005627; Mon, 28 Feb 2022 14:53:09 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 21SKr7Xe005624; Mon, 28 Feb 2022 14:53:07 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 28 Feb 2022 14:53:07 -0600 From: Segher Boessenkool To: Linus Torvalds Cc: Christian =?iso-8859-1?Q?K=F6nig?= , linux-wireless , alsa-devel@alsa-project.org, KVM list , "Gustavo A. R. Silva" , linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org, Rasmus Villemoes , dri-devel , Cristiano Giuffrida , "Bos, H.J." , linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com, linux-arch , CIFS , linux-aspeed@lists.ozlabs.org, linux-scsi , linux-rdma , linux-staging@lists.linux.dev, amd-gfx list , Jason Gunthorpe , intel-wired-lan@lists.osuosl.org, kgdb-bugreport@lists.sourceforge.net, bcm-kernel-feedback-list@broadcom.com, Dan Carpenter , Linux Media Mailing List , Kees Cook , Arnd Bergman , Linux PM , intel-gfx , Brian Johannesmeyer , Nathan Chancellor , dma , Christophe JAILLET , Jakob Koschel , v9fs-developer@lists.sourceforge.net, linux-tegra , Thomas Gleixner , Andy Shevchenko , Linux ARM , linux-sgx@vger.kernel.org, linux-block , Netdev , linux-usb@vger.kernel.org, samba-technical@lists.samba.org, Linux Kernel Mailing List , Linux F2FS Dev Mailing List , tipc-discussion@lists.sourceforge.net, Linux Crypto Mailing List , linux-fsdevel , linux-mediatek@lists.infradead.org, Andrew Morton , linuxppc-dev , Mike Rapoport Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr Message-ID: <20220228205307.GD614@gate.crashing.org> References: <20220228110822.491923-1-jakobkoschel@gmail.com> <20220228110822.491923-3-jakobkoschel@gmail.com> <2e4e95d6-f6c9-a188-e1cd-b1eae465562a@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Feb 28, 2022 at 12:14:44PM -0800, Linus Torvalds wrote: > On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds > wrote: > > > > We can do > > > > typeof(pos) pos > > > > in the 'for ()' loop, and never use __iter at all. > > > > That means that inside the for-loop, we use a _different_ 'pos' than outside. > > The thing that makes me throw up in my mouth a bit is that in that > > typeof(pos) pos > > the first 'pos' (that we use for just the typeof) is that outer-level > 'pos', IOW it's a *different* 'pos' than the second 'pos' in that same > declaration that declares the inner level shadowing new 'pos' > variable. The new "pos" has not yet been declared, so this has to refer to the outer "pos", it cannot be the inner one. Because it hasn't been declared yet :-) Compare this to typeof (pos) pos = pos; where that last "pos" *does* refer to the newly declared one: that declaration has already been done! (So this code is UB btw, 6.3.2.1/2). > If I was a compiler person, I would say "Linus, that thing is too ugly > to live", and I would hate it. I'm just hoping that even compiler > people say "that's *so* ugly it's almost beautiful". It is perfectly well-defined. Well, it would be good if we (GCC) would document it does work, and if someone tested it on LLVM as well. But it is really hard to implement it to *not* work :-) > Because it does seem to work. It's not pretty, but hey, it's not like > our headers are really ever be winning any beauty contests... It is very pretty! Needs a comment though :-) Segher