From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C9EB2D46A9 for ; Sat, 17 Jan 2026 23:32:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768692767; cv=none; b=Eb+CFUmNwguJGNsPaVs4p0Xq7eta2wOttoRlkmqHes1oRWI/4rvUogZ6UsbfLgy5xRCdU4fEKAWM0f8IGH7Z0G60nGqPA1jHyaOQyyaG5IOXj1e9H6snkSO0Wft4SP789pmG68FtmYU6ajKEL3O8JgOrm40uN6aaa04fWLn1SWw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768692767; c=relaxed/simple; bh=tswY9sr+6D0K7NCsWgYHjxJJImhSdxWRig3FrPEYGLE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SEavdUR1mzsVd9kEMsAiGX4RWdXUhC2DoC6wqZkE+9arOU7FnsHKWm2PBNSeYgB+vd335tIibRxpPq+zheMaGZi6nmHxCQ1R/Mh6pWTHVIhtKENxySMBrbB/zuVDK1O0KHpL/yBGop4uVdqV+rWpaIbZBtyS4dsSYVxq8YFdjps= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Qyxmd43S; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Qyxmd43S" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso20928765e9.2 for ; Sat, 17 Jan 2026 15:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768692764; x=1769297564; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=JXyjAWiL9FfOIdQk6OYLsAjwy2W6lQPX58xL+qrHaN8=; b=Qyxmd43SMAgLpk3oDz02VZW96abGEE+ZD83qpA1XB8PeOVDHuNX0bKDtufYLlgBa82 QfyrB1rYosoa+OMhN2bkRXbzOKHX9FMM/yGt0uix/9sCX/kx5lAvarIe04pOh6yiK2/s Ujji+Xhs3sW7Fp5iR+mzV0P9KPVlKSwAvJSKZ9A7txQc3n0ZAV+Tm9irDu/Q16QVSefk Ufs+UhYvq6ic7wF7sx4stMba9oSyv8TQe8N/xEYmnKf9HrJPDHckdyC1WiGS46OlqS1n y7HTFUf7VPpGpoj0mQb50dL2gw/bt6IDzpI2gS1EYGuPCjd7PKkQywnADfq3znb+XGxu iXYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768692764; x=1769297564; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=JXyjAWiL9FfOIdQk6OYLsAjwy2W6lQPX58xL+qrHaN8=; b=N+x+pDnfeGTPVqPkMNzYaoA3kgKO8l8OlBZS5rvxrsZ587ENx8bVc9iuXF9AOm7Rub PlO9JrNR7PGebS9e9ny41MaiOt8xY95giIA9VNvODhvRYoJy80FpgsA+eUa5/vcWo7Uy yFnKtQIljkcydk5H/skJHqdgRQPNJIT4Lc3AKMsCXxQxWWUoYAO/tfFGcwWpGMBRns21 BiX7++dqGLV39aTeL+f1RiveS6ADyXJ+0mTcFrHIbrfuQlpWuJx6F87bbyTEzGAOrsTP wjeIzHTFIYddXJeyML4/g7FSP7Dk1jtga33NzCBsTpVxuUPWTCvT/o1JhbRgYBA9qOji JlPw== X-Forwarded-Encrypted: i=1; AJvYcCVH8UXKv2odlRIJgIz96lrnd4UKj9V8AeWNNOEWm8uWSsvQQxqSGFR/67os88gg0mjBSJ3JE1iHxJjrmnw=@vger.kernel.org X-Gm-Message-State: AOJu0Ywlax6Lpue1TWH2yL9PsJgVE4p/Bfu0buuT501NfH+wAomqXlrU 65a1JBlZBbw5xZ6dkr6vF0YSrasNreUJfGjlLixZ8hJ2pIxlnERvIxsT X-Gm-Gg: AY/fxX62GLHAsxfk5yMHqx+wlj1BXBifqAnZ9oVVBBZv3uyYK/IBuS4WbMKnkrsH8hK focuidOSpBQzBt1GmK5mnWMu1ZaZf/VeRfltmmaSPOTcBg7Byk6AnUTnKReoP9+NCg+E/dr3eVw m6UCZoGyVnHVKYY6UJ9iXzTrPCbpgcda0z+rQzDJDklpoZVZqIjUYtmiD1VtBFD6ZFNT5FTe+ML /fFEuNaOv5XrXkuVPMAARjmPSfUls3iHbKcnvDsylZiJiTDzrvl/1cynI7Icx19I0ldjlG+5vjD hhFsb28rkU216VzIn8k0nkFGeaT9eJWSkOMlEXHKxw4Btl32aey14RlY8lKo54zqRZStDSqVJot hcR5DHjXWlTB6VCf7Rezt3SyJIYPPlEmomv/qoTZO82pEQszBAauP52ch54+5cAcc0hGrKe3Srq fl9MJC+aqHMZzv25CIdmmQ951VbZaGvNvwon0hpHamMFgrVYNzCdKihSbhEhshNek= X-Received: by 2002:a05:600c:b93:b0:480:1db1:b44d with SMTP id 5b1f17b1804b1-4801e34cab5mr95807995e9.27.1768692763561; Sat, 17 Jan 2026 15:32:43 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4b2755absm211685415e9.15.2026.01.17.15.32.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Jan 2026 15:32:43 -0800 (PST) Date: Sat, 17 Jan 2026 23:32:41 +0000 From: David Laight To: "Bird, Tim" Cc: Alexey Dobriyan , Steven Rostedt , Andy Shevchenko , James Bottomley , "ksummit@lists.linux.dev" , Dan Williams , linux-kernel , Dan Carpenter Subject: Re: Clarifying confusion of our variable placement rules caused by cleanup.h Message-ID: <20260117233241.5ba95b2d@pumpkin> In-Reply-To: References: <58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com> <7b37e1cb-271e-49fe-a3ee-5443006284e1@p183> <20260102095029.03481f90@gandalf.local.home> <38d7b19f-b6ff-437b-bc88-fa2047ca556a@p183> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 17 Jan 2026 16:54:43 +0000 "Bird, Tim" wrote: > > -----Original Message----- > > From: Alexey Dobriyan > > > > On Fri, Jan 02, 2026 at 09:50:29AM -0500, Steven Rostedt wrote: > > > On Wed, 31 Dec 2025 13:17:32 +0100 > > > Andy Shevchenko wrote: > > > > > > > > There was variation of this type of nonsense with headers (not only it has > > > > > to be sorted alphabetically but by length too!) > > > > > > > > By length it indeed sounds weird, but alphabetical is the natural language > > > > order everybody learnt from the daycare / school years, so it's properly > > > > programmed in our deep brain. Having that allows to find easily if anything one > > > > is interested in is already being included. Also it allows to avoid dup inclusions > > > > (was there, fixed that for real). So, it's not bad. > > > > > > Actually, I like the "by length" because its aesthetically easier on the eyes. > > > > > > Alphabetically is fine, but either one helps in catching duplicate headers. > > > > Such rules for headers are mostly harmless -- headers are supposed to be > > idempotent so ordering doesn't matter. But if ordering doesn't matter > > why have a rule at all? > The rule is (or at least was, at one point) helpful to reduce the likelihood > merge conflicts during patch application. I know patch and quilt still > don't ignore mismatched #include lines in the patch context, even > though #include lines in C are independent of each other. I'm not sure if git > handles this better or not. I prefer headers to be grouped with system headers first, then subsystem ones and finally local ones. Alphabetic ordering is, IMHO. silly. If you know the name of something you cam search for it. When you don't know the name you want it to be near something you do know. So in a book on a cpu instruction set you want all the arithmetic instructions next to each other not spread throughout the book. For C variables you want the definition where you can quickly find it when looking at the code. Hiding it in the middle of a large block of statements doesn't help (especially if -Wshadow isn't enabled when you might find the wrong one). If a variable is only used in a very short block, it can be defined at the top of the block - otherwise it really needs to be at the top of the function. But don't initialise things that aren't semi-constant and are only used way down the function - that just makes you have to go hunting for a value. The location of these definitions has to be about making code easier to quickly read. David > > When everyone appends new #include lines at the end of the block of lines, > there is more likelihood of a patch conflict right there. If the #include lines > are instead sorted in some fashion, it reduces (but obviously does not eliminate) > the possibility of a patch conflict. > -- Tim >