Received: by 2002:a05:7412:cfc7:b0:fc:a2b0:25d7 with SMTP id by7csp368071rdb; Sat, 17 Feb 2024 12:02:52 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVe1B7G/0q6qyjX4thMWENineO63EuJdKeqInn5F2SzLAYYyqGSG1yqM61TPHtmjnxEsw4VsyFDPxUB/nT3FiuR6OaLpRXRBN2IgxwkCg== X-Google-Smtp-Source: AGHT+IFtgpB4VO8dZzNY2Pylyu3Scwlu3D6cIDhUj3k5nNm6EuAFCQmm8l8BwzRy7CoWYw9BUw6B X-Received: by 2002:a05:6a20:9590:b0:19e:9ca7:7c94 with SMTP id iu16-20020a056a20959000b0019e9ca77c94mr11284377pzb.9.1708200172513; Sat, 17 Feb 2024 12:02:52 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708200172; cv=pass; d=google.com; s=arc-20160816; b=vWTpWZpsnEB5fKyS8iL3bhmH5twvptycWRqnbOIN5z8kI1IHVSQ/kkhPubtTGy7aIE TDbIff12X8YjGZ5DRGDw/wqi3RsjVunvfJEwhU6mojQYcI4S3OXnddUU0LRHd9A7DxtU djxh6vDZ47sHV90QpGutQ5SWfnqI0Pz11HlvPhbpwsLQo7XQAYOjRp5s1LZmaiKQ6bjn VVrctV+kuycM/tXWof7oVGECfnsNrN1nawSAjPwborhePHFGt3EQ97SgvmvYY+kJgYeE m9HihgmTExtI7ZE07MUYPeCs5RPk1T9lxJ2T56tPQ6GwQbaQj5eNs7xQtuPC9oAQaVm2 +cLw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:references:in-reply-to:subject:cc:to:from:date :content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:dkim-signature; bh=bx66MyNuRcTUBsAELwhQfX2rX5YS0JkrALXZB5THPYM=; fh=pqZfv0IedVeVZrIIVoWbMpH9NiRvjcEPeh7We6exixA=; b=Pm3yMPLVrHrBJX4bjm+91dgsDKDxL0o9g9PvhfxCd3eYFzpSsqbLUhYrqMtTqM05qG l6muLFzioPywY67/36h0xgiWHl4cbFSuoQ0g2eyb1dXCfu6+HEB0Ds1OIhSyjkbiIM7R AAKT2qTqiL6mEh++nLntUhTurxVyyYrcP8VxQ+E2pKpLo1LpbSfMcDtovPlDFawseYtT L9yYTjUHMW4B13f0HHdXzEzzzN5GRTpne8YQvPGJdbFtdEi0JQV86/P24VF4fJ+OtRJK fxxpdNtiBgUzr1cnOAagbLWxQjlCYaPL6zoTUhJuAoT6PArM8xjNf/dTpYX50N1D3FHx C+cA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@posteo.net header.s=2017 header.b=RwmGKLgP; arc=pass (i=1 spf=pass spfdomain=posteo.net dkim=pass dkdomain=posteo.net dmarc=pass fromdomain=posteo.net); spf=pass (google.com: domain of linux-kernel+bounces-70046-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70046-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=posteo.net Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id x64-20020a638643000000b005ce0474353csi1836905pgd.238.2024.02.17.12.02.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Feb 2024 12:02:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-70046-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@posteo.net header.s=2017 header.b=RwmGKLgP; arc=pass (i=1 spf=pass spfdomain=posteo.net dkim=pass dkdomain=posteo.net dmarc=pass fromdomain=posteo.net); spf=pass (google.com: domain of linux-kernel+bounces-70046-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70046-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=posteo.net Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 2D9FD28365E for ; Sat, 17 Feb 2024 20:02:52 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4D4677E785; Sat, 17 Feb 2024 20:02:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=posteo.net header.i=@posteo.net header.b="RwmGKLgP" Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 136F47E599 for ; Sat, 17 Feb 2024 20:02:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.67.36.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708200151; cv=none; b=CNap1hUv9oZgA3unGpch6B05yLwmIj6lfcCj4QXXP5ywOCCuWsqqRvTwlrEwza9pcxObHG+OGprdRNEGaHhjHWYLZ/Tct5RaEpfBRQ/fnIFq4MaCaQOrjhuNU0cS7MeEqdXBXojRGuSZvK2JS/TDGTS4JDG6M5gheO932F1w+2Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708200151; c=relaxed/simple; bh=0C1CBOiQuvzSBak2fykgvRp1ayDDC7QbGItT6k4iANU=; h=MIME-Version:Content-Type:Date:From:To:Cc:Subject:In-Reply-To: References:Message-ID; b=aKF2Dtt8BJK7qLiXvfCMQFV7N9aRgZrYPlLG3mZ6J7lfSlPpJr181VjxR6BvQPCAK0n0q7BrnicpB5BjKvO4cKAaObopXTkLlJMHJRmPg8JUwuX5tpZkEJiyZIUfT74sNE/O5KEY2GeqObP1dIOatAPendEd8Mnlu/8F0iNV0eo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=posteo.net; spf=pass smtp.mailfrom=posteo.net; dkim=pass (2048-bit key) header.d=posteo.net header.i=@posteo.net header.b=RwmGKLgP; arc=none smtp.client-ip=185.67.36.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=posteo.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=posteo.net Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id BE533240029 for ; Sat, 17 Feb 2024 21:02:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1708200144; bh=0C1CBOiQuvzSBak2fykgvRp1ayDDC7QbGItT6k4iANU=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To: Cc:Subject:Message-ID:From; b=RwmGKLgPByQ82toydTLc96K7pNJjfOlubasx/UTDpuz7439Rtc7bLbB6HeTmzQ4mh eHsYXL8CEO9+PAzhds5EaJFWcMqdWBXtdkhxsUci2ArSckZr7Qk7evLPll0ztfH5gK Zu0gas9qlAUjtsCiBB+wOnWONWOkhoDwT0kxWI+PNyn5pu1x1EFyGaEo9stTAFFir9 /oe9/RDod527MfeBVB0cze5YRY2+wouIr+M8aSGdQdjjEV8Gu9LvRmoWALnJej+nCS Kzj2eRgu9Oy4mkocv2T32hhfAi2x80h+JULb25QbefI8lQCd6ScY7toGXKsE5Ty2UY zJWnhc4Ryrn5g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Tcfpl2RSmz6txR; Sat, 17 Feb 2024 21:02:23 +0100 (CET) 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; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 17 Feb 2024 20:02:23 +0000 From: Yueh-Shun Li To: Andrew Morton Cc: Mark Brown , Andy Shevchenko , Herve Codina , Christophe Leroy , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] minmax: substitute local variables using =?UTF-8?Q?=5F=5FUNIQUE=5FID=28=29?= In-Reply-To: <20240215140704.7989cc915a8f92a6358e7455@linux-foundation.org> References: <20240215185820.2285834-1-shamrocklee@posteo.net> <20240215140704.7989cc915a8f92a6358e7455@linux-foundation.org> Message-ID: <60c9477d80241b2aa363ed8ab4e3a84b@posteo.net> On 2024-02-16 06:07, Andrew Morton wrote: > On Thu, 15 Feb 2024 18:58:15 +0000 Yueh-Shun Li > wrote: > >> Substitute identifier names of local variables used in macro >> definitions inside minmax.h with those generated by >> __UNIQUE_ID(prefix) >> to eliminate passible naming collisions. >> >> Identifier names like __x, __y and __tmp are everywhere inside the >> kernel source. This patch ensures that macros provided by minmax.h >> will work even when identifiers of these names appear in the expanded >> input arguments. > > Makes sense I guess. However I do wonder how far this goes: > > # grep typeof include/linux/*.h | wc -l > 313 > > Many of these are locals being defined within macros. Do they all need > changing? Regarding the extent of changes needed, you raise a valid point. Searching in include/linux with regular expression `typeof\([A-Za-z0-9]+\) __`, there are about 20 header files contain macros with temporary variables prior to this patch, and 10 of them (including minmax.h) uses generic variable names such as __a, __x, __v, __val, __p or __ptr. > If so, do we really want to implement this fix for what has > always been, to my knowledge, a non-problem? While the occurrence of collision is minimal in the current Linux kernel source, the presence of variable names prefixed with long underscores hints the potential issue. Although Linux kernel coding style recommends suffixing temporary variable names per-macro to avoid collisions[1], prefix more underscore (_) before the colliding local variable name seems to be a workaround that receives wider adoption. Examples include ____ptr in three include/linux/*.h files and ______r, ______f in compiler.h. commit 24ba53017e18 ("rcu: Replace ________p1 and _________p1 with __UNIQUE_ID(rcu)") shows how __UNIQUE_ID() could be a more systematic solution. A probable cause of __UNIQUE_ID() not being widely adopted as long-underscore variables is that the __COUNTER__ support was not available until to GCC 4 and Clang 2. It was until recently that __UNIQUE_ID() provided by compiler.h was unified to use __COUNTER__ by commit a8306f2d4dce ("compiler.h: unify __UNIQUE_ID"). This patch aims toward minmax.h because it provides general functionality, such as minimum, maximum and variable swapping, that are used across subsystems. As for other headers, those with long-underscore names and those with wide application could be changed first. Thank you for your valuable feedback. Best regards, Shamrock [1]: https://www.kernel.org/doc/html/latest/process/coding-style.html#macros-enums-and-rtl