From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 E48E413DBB3
	for <linux-kernel@vger.kernel.org>; Thu, 15 Feb 2024 22:07:05 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1708034826; cv=none; b=H9huENDaFat3CJwVHE3VoucysEa5+fnRUVf9qmUVRaT0ULTvHg2Lu8tJl8IedGMRgPYhQZj5SugYb9opUGcJDXOB3l1IE/tUBuxLaRXtwAuUQkN6+IowEWZiOyaWxSR2v3PtySujW9wjdNSvk6n1Ja4A8mgaIME1+zaCs2mEiLs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1708034826; c=relaxed/simple;
	bh=Y53d7Cs+dFgmuD6d4R+/d5q9x29NLpaF6Bm05Sju5pc=;
	h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References:
	 Mime-Version:Content-Type; b=YlFQCsvp+sp0OcTYtmP+w+L9d/YfhKJur3Mi5uCH5U+5qFIXeAUvCh/4KXuKLh2cgeGdfg0aQ2JjA60cOugVFc19KvNMF7ytjWXXC8wiH8WKeul0qtKS/gY1+63Vu392wN69/Pt65c9vhvP4gjNipOY1Ao45BAfyJOPsmw0NM7o=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=YmmKduh/; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="YmmKduh/"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FDDEC433F1;
	Thu, 15 Feb 2024 22:07:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1708034825;
	bh=Y53d7Cs+dFgmuD6d4R+/d5q9x29NLpaF6Bm05Sju5pc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=YmmKduh/+Pp+xpF+vwu/CkV1ZFMf9tPXv5xyGleKwGJwIA+eCbwj6m51PeeWGePAP
	 H4UP1S2q+TeC4VQDYx/hqTmIfEPobddtdzo7AU5+0splHUaWetNGEnyWcTzAxpJCr+
	 9ZctyAAWG2sl1JlowDfJY0+IrCAbX2L8PkcFn/bQ=
Date: Thu, 15 Feb 2024 14:07:04 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Yueh-Shun Li <shamrocklee@posteo.net>
Cc: Mark Brown <broonie@kernel.org>, Andy Shevchenko
 <andriy.shevchenko@linux.intel.com>, Herve Codina
 <herve.codina@bootlin.com>, Christophe Leroy <christophe.leroy@csgroup.eu>,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] minmax: substitute local variables using
 __UNIQUE_ID()
Message-Id: <20240215140704.7989cc915a8f92a6358e7455@linux-foundation.org>
In-Reply-To: <20240215185820.2285834-1-shamrocklee@posteo.net>
References: <20240215185820.2285834-1-shamrocklee@posteo.net>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 15 Feb 2024 18:58:15 +0000 Yueh-Shun Li <shamrocklee@posteo.net> 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?  If so, do we really want to implement this fix for what has
always been, to my knowledge, a non-problem?