Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp327426yba; Sun, 31 Mar 2019 00:01:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqz4ypwVjSwC7sCdezXw2LyMC5Ft7Uh+xvfotFFSI0w0YqoShYVwSyIAnPXdsysm54R6O0Oj X-Received: by 2002:a63:4612:: with SMTP id t18mr54480859pga.56.1554015713519; Sun, 31 Mar 2019 00:01:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554015713; cv=none; d=google.com; s=arc-20160816; b=tHLocm3NFaLWxZg3RMlSh/UBDf3JBKk7X1Oqu0Zler08THri9/C1qylg7G/FWLAc13 QawsG1XJGYY0ExDHErM++dtetXKnCmvuhdh6nFZNWwHh2lVgr0v2q2tqoViVuSOpWacI s1Eu+7JJxYRJhdGFK62a05UlW07USO1ycu3SMHiqsCHP1Anj7q5svxPcAh9UEnWQlJxB 8GtzhuBqXm2R84WcqXbMjbDa4UYd5qXXUN0IWScwMXJpf0unrDt7/pSzPGSF9xSHPgVp Z60D59jPY5wsSrmbo4PFPnGz7hvjo3L3IWPQ8ReoTs8MdLW/lF7uR2BflwTjO4dYG1Ec gy7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:message-id:date :mime-version:subject:references:in-reply-to:cc:to:from :dkim-signature; bh=q8QLXGODLudj41ocQ19De3Mh7BhghNHmPdLkc9qJ9+A=; b=h1x36YZAiR3F0NrvenX3q33kxzA8HjSl08TXGdIpatf4UOXtuYbva8oFCVt98Eaqy4 R+KLiBkSykCn/M/6zOGFrwV8PzQwjntKmptbzQrojRxZllKrmLyKvuQHncCvDFU8yNo1 Fnu+bp9DRpABVRXKf0pBp+m2Y7c+IxYixniToMzx2KOVFCj4+S4ZqpbrSNJ1boYmjXt6 6N0SdAIkCH+csM8SfowifPIYmNT0NvFLASSfEumhfehI0r6P0XrEs1FhQfoZ6J7a30Tc V/0nUwPIj4wkGO6wGA2Y2jPiNlyJeu6dqoxOD8LgUgFIw59x5XYptl3yv3j+xK3cttlm IhCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yandex.ru header.s=mail header.b="Ew/4p59M"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b8si6448664pla.290.2019.03.31.00.01.26; Sun, 31 Mar 2019 00:01:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@yandex.ru header.s=mail header.b="Ew/4p59M"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726336AbfCaHA2 (ORCPT + 99 others); Sun, 31 Mar 2019 03:00:28 -0400 Received: from forward103j.mail.yandex.net ([5.45.198.246]:52990 "EHLO forward103j.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725886AbfCaHA1 (ORCPT ); Sun, 31 Mar 2019 03:00:27 -0400 Received: from mxback1j.mail.yandex.net (mxback1j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10a]) by forward103j.mail.yandex.net (Yandex) with ESMTP id A162E674014F; Sun, 31 Mar 2019 10:00:22 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback1j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Rt4wCa2BxV-0IEq6xtR; Sun, 31 Mar 2019 10:00:20 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1554015620; bh=q8QLXGODLudj41ocQ19De3Mh7BhghNHmPdLkc9qJ9+A=; h=Message-Id:Cc:Subject:In-Reply-To:Date:References:To:From; b=Ew/4p59MkJHVLnmiq7z/V83sYjWuGYNBW9W7RtCYs8xY4Anbtnr+WtdH9fiNUapG0 n08oXJPak6SfriaY3r/4720v4X1BrbloVNLrmroTo8fqQLJsFKu0kBc5B4i22jg2r9 keeae2rfxM7gp+EpRSdcNWNbLDKV8ckv5SFNJhEw= Authentication-Results: mxback1j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt1-cd60b8ae9bb9.qloud-c.yandex.net with HTTP; Sun, 31 Mar 2019 10:00:18 +0300 From: Andrey Abramov To: George Spelvin , "gregkh@linuxfoundation.org" Cc: "adrian.hunter@intel.com" , "ard.biesheuvel@linaro.org" , "benh@kernel.crashing.org" , "bp@alien8.de" , "darrick.wong@oracle.com" , "dchinner@redhat.com" , "dedekind1@gmail.com" , "hpa@zytor.com" , "jlbec@evilplan.org" , "jpoimboe@redhat.com" , "linux-kernel@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" , "mark@fasheh.com" , "mingo@redhat.com" , "mpe@ellerman.id.au" , "naveen.n.rao@linux.vnet.ibm.com" , "paulus@samba.org" , "richard@nod.at" , "tglx@linutronix.de" , "vgupta@synopsys.com" , "x86@kernel.org" In-Reply-To: <201903302015.x2UKFnSL003850@sdf.org> References: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>, <20467491553964233@myt4-c0b480c282c8.qloud-c.yandex.net>, <20190330183826.GB21828@kroah.com> <201903302015.x2UKFnSL003850@sdf.org> Subject: Re: [PATCH 5/5] Lib: sort.h: replace int size with size_t size in the swap function MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 31 Mar 2019 10:00:18 +0300 Message-Id: <20434561554015618@myt1-cd60b8ae9bb9.qloud-c.yandex.net> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 30.03.2019, 23:17, "George Spelvin" : > On Sat, 30 Mar 2019 at 19:38:26 +0100 greh k-h wrote; >>  On Sat, Mar 30, 2019 at 07:43:53PM +0300, Andrey Abramov wrote: >>>  Replace int type with size_t type of the size argument >>>  in the swap function, also affect all its dependencies. >> >>  This says _what_ the patch does, but it gives no clue as to _why_ you >>  are doing this. Neither did your 0/5 patch :( >> >>  Why make this change? Nothing afterward depends on it from what I can >>  tell, so why is it needed? > > It's just a minor cleanup, making things less surprising for future > programmers. As I wrote in a comment in my patches, using a signed type > for an object size is definitely a wart; ever since C89 it's expected > you'd use size_t for the purpose. > > The connection is that it's a natural consequence of doing a pass over > every call site. > > You're right it could be dropped from the series harmlessly, but it > comes from the same work. But it's all of *three* call sites in the kernel > which are affected. Surely that's not an unreasonable amount of churn > to clean up a wart? George Spelvin is absolutely right: "It's just a minor cleanup, making things less surprising for future programmers." 31.03.2019, 00:51, "George Spelvin" : > It was so obvious to me that I didn't question it, but you have a > good point and I'm sure Andrey can clarify. Thanks for the attention! I thought that it is obvious enough (argument called "size" should be of type size_t in the 90% of cases). Should I resend this patch with better explanation "why"? -- With Best Regards, Andrey Abramov