From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 56D0546AEEA for ; Wed, 3 Jun 2026 12:01:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780488072; cv=none; b=aAfnBiaagoguFU8MrzqQTL0oCwZpaNBdm97KC1PsZN+gDfUGLZpyzp1G18ABBKNmzj+r+XlIgjQlfenOVLskpxAZ0pR4QzPWoKTT4D9y2b+LFvcX8zCwI3krr8LQqjNzS6mQwGk0z/LGwa6UXGi3k1usTmxFF3ejex3yWQaT8pI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780488072; c=relaxed/simple; bh=qUk0Deq6xCmmcWqJTCh1VhO/zLoXsRJNASRRiZ5U8o4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AZDvd7pE19ezgZrVWaXF+uopqMoN+kdUeqlDj8357deIBkcQO90pODAESOpW3qFIWezr4DA1sE7GbIiqZ1Z+o5rq8qqcM2A/5N441yBwJ/5ahSrypnj+otptarhZ9UKQnSaIjY6tsa5eDHWUqmGFaLhmt+fVmo9XOJM9tKuYrTg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=ZUshP5g1; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="ZUshP5g1" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4906869f0cbso122320115e9.1 for ; Wed, 03 Jun 2026 05:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1780488070; x=1781092870; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IGKWrcyMiaj8r+JWiffS2JraYN7ejkKwmvwLBEykKsM=; b=ZUshP5g13Rvm4C620bKBKVl+8hLXZcY22ysvmnDDFBENfb/Xv2uNzPAawGz6BhMMag +RO/1a4PJdknMPspJkXRdL/6O1rbIzX879I5NezBa+/mO/z1Ju3Q/98j76GSTDbqMOw/ m/RskaOlss/tq64PJ4eIbJoaQ16aRrOciAhG87aRKq0p7QMeTXR2WsA+iqurztLKbNC2 tqOSkDDdNwRoEEJxqzxf3LWNn6SMpmlb2YsDn0/+MaiD7daJs9mQnQMJzBjx5fiAeAOk tqda1K0cXJQLDKGT3f8XsfWaHjw89ua0pqs1frpXQT6WruWug84nosQoU6O4rR7ciSBp vF5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780488070; x=1781092870; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IGKWrcyMiaj8r+JWiffS2JraYN7ejkKwmvwLBEykKsM=; b=hUSifg3YJJsd3dFuEYmmlkBrj6m04INp8VokIMb7MfCNSDm6D1aE7sOxcx6FV5q/kR R5IhMEX1MFCoFHxt9GklV1uAvsWgFj8kBOCEe0TBKue4lfKetf+UtisTMfcE0P5S9YOr deb7WA2bun2E64EA1qNVbbLf/9c6J/I1ylwln8kso/FELoMvwUjbpYEpvWE20VSoIiUy vbSyL6SuwbMWf5GpelS6Ar9FHekHCouoLVaOKneTZl9cizGny4oZQi07Sj4De4X+mhUn 0IUNSwtAdCj3MSIL1IgjABoL1FbHNCPfBLkfZbhl9UuBrRLnNKvXsLfQ3G6t2JIdWE/V tvag== X-Forwarded-Encrypted: i=1; AFNElJ8PlgGG4M62RDBR+nkMECX9wk0F4nPKxH9yKcxrE4NROwGQY61qLeM/t67HxQLP35nKN6f/m80JAdN3Ufk=@vger.kernel.org X-Gm-Message-State: AOJu0Yx6dTj6ymi55PBY90qqEPuuQca0KQ2TzTiSU8+2v08ETwDoIhYk eq26Bi62UUfoZFxYf48gJjOUY30Ss/sDl5HP6TFvdhhwZGp8/sqUGxcxniHptRyCcHHvX0kFp60 l0lZQ X-Gm-Gg: Acq92OEpivkmP5n4g+KggTOdq2Ur7KrBXwHpO6dCFr6+hfGo3a85oiP1rhTC9PwFp9/ E8WerZjbAy+wAUG64oseQsApfxK1y/gFCMa0ZcnXBh4ZxyKbIqdHSDMXHOzB1BTgq8HQOHfpBm2 YVzQWJN2EaNRD3Dqcurp1sPrvUaxbbYuOs8YKsB27aFM1eJq8Sqc7ACwokFdAVrijXLXa+/XMsd KWzi0cH45iHm0KSJTS7S8LOEgklSB9LxD9CAsCExv/UL11anYaBtgn1K8q0YA2NzNKU0ovkVHg+ wqcUlTlk1IaBAXc4o+AEOkOjna+Z5FEL4R/rIF/szu3LoRtc4MnV3HVRGaGKOZXofwvQTip9tpx LUoJ1lwtPdhOIgKOzJNNc9Z02AnUGmcwPn8xJvufFxR3ZyROvQN4I6JmsGw0ELOyC/gDwGT0oLN WNWG21g3FGlgiI0a7ig+DEJ5r4+A== X-Received: by 2002:a05:600c:4e0a:b0:489:1c32:210d with SMTP id 5b1f17b1804b1-490b5fd8a86mr53527685e9.15.1780488068248; Wed, 03 Jun 2026 05:01:08 -0700 (PDT) Received: from pathway ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490b7a7cb85sm49220685e9.1.2026.06.03.05.01.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 05:01:07 -0700 (PDT) Date: Wed, 3 Jun 2026 14:01:05 +0200 From: Petr Mladek To: David Laight Cc: Thorsten Blum , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] lib/vsprintf: replace min_t/max_t with min/max Message-ID: References: <20260518123145.79411-3-thorsten.blum@linux.dev> <20260603103539.13028bf4@pumpkin> 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-Disposition: inline In-Reply-To: <20260603103539.13028bf4@pumpkin> On Wed 2026-06-03 10:35:39, David Laight wrote: > On Thu, 21 May 2026 15:49:12 +0200 > Petr Mladek wrote: > > > On Mon 2026-05-18 14:31:47, Thorsten Blum wrote: > > > Use the simpler min()/max() macros since the values are all compatible. > > > > > > --- a/lib/vsprintf.c > > > +++ b/lib/vsprintf.c > > > @@ -1208,7 +1208,7 @@ char *hex_string(char *buf, char *end, u8 *addr, struct printf_spec spec, > > > } > > > > > > if (spec.field_width > 0) > > > - len = min_t(int, spec.field_width, 64); > > > + len = min(spec.field_width, 64); > > > > Honestly, I do not see any big advantage in replacing the macros. > > In fact, the min()/max() macros are even more complex because > > they check compatibility of the compared types. > > But min_t() is often worse that just letting the compiler promote > a negative signed value to a very large unsigned one. > > There are basically three common misuses: > 1) Using the type you want the result to be. > 2) Using the smaller type, including 'long' v 'u64' on 32bit. > 3) Thinking min_t(type, a, b) is the best way to compare items of > type 'type'. > > All not helped by checkpatch suggesting that: > min(foo, (type)bar) > is 'an opportunity for': > min_t(type, foo, bar) > but the latter is: > min((type)foo, (type)bar) > and you never need both casts. > > There are also a few of the pointless/buggy: > min_t(u8, foo, U8_MAX) > but you'd notice that the test: > if ((u8)foo > U8_MAX) > doesn't do what was intended. > > Ideally min_t() ought to be killed, but it is a big job. > (The sort of thing Linus could because of his 'god' bit.) Andy, David, thanks for feedback. Fair enough. Thorsten, thanks for the patch. I have just pushed the patch into printk/linux.git, branch for-7.2. Best Regards, Petr