linux-kernel - Re: [PATCH 5/5] Lib: sort.h: replace int size with size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <201903302015.x2UKFnSL003850@sdf.org>
Date:   Sat, 30 Mar 2019 20:15:49 GMT
From:   George Spelvin <lkml@....org>
To:     gregkh@...uxfoundation.org, st5pub@...dex.ru
Cc:     adrian.hunter@...el.com, ard.biesheuvel@...aro.org,
        benh@...nel.crashing.org, bp@...en8.de, darrick.wong@...cle.com,
        dchinner@...hat.com, dedekind1@...il.com, hpa@...or.com,
        jlbec@...lplan.org, jpoimboe@...hat.com,
        linux-kernel@...r.kernel.org, linux-snps-arc@...ts.infradead.org,
        lkml@....org, mark@...heh.com, mingo@...hat.com,
        mpe@...erman.id.au, naveen.n.rao@...ux.vnet.ibm.com,
        paulus@...ba.org, richard@....at, tglx@...utronix.de,
        vgupta@...opsys.com, x86@...nel.org
Subject: Re: [PATCH 5/5] Lib: sort.h: replace int size with size_t size in the swap function

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?