linux-kernel - Re: [PATCH 01/10] floppy: cleanup: expand macro FDCS

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wi4R_nPdE4OuNW9daKFD4FpV74PkG4USHqub+nuvOWYFg@mail.gmail.com>
Date:   Mon, 24 Feb 2020 13:53:47 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Willy Tarreau <w@....eu>
Cc:     Denis Efremov <efremov@...ux.com>, Jens Axboe <axboe@...nel.dk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>
Subject: Re: [PATCH 01/10] floppy: cleanup: expand macro FDCS

On Mon, Feb 24, 2020 at 1:24 PM Willy Tarreau <w@....eu> wrote:
>
> Macro FDCS silently uses identifier "fdc" which may be either the
> global one or a local one. Let's expand the macro to make this more
> obvious.

Hmm. These macro expansions feel wrong to me.

Or rather, they look right as a first step - and it's probably worth
doing this just to have that "exact same code generation" step.

But I think there should be a second step (also with "exact same code
generation") which then renames the driver-global "fdc" index as
"current_fdc".

That way you'll _really_ see when you use the global vs local ones.
The local ones would continue to be just "fdc".

Because with just this patch, I don't think you actually get any more
obvious whether it's the global or local "fdc" index that is used.

So I'd like to see that second step that does the

    -static int fdc;                 /* current fdc */
    +static int current_fdc;

change.

We already call the global 'drive' variable 'current_drive', so it
really is 'fdc' that is misnamed and ambiguous because it then has two
different cases: the global 'fdc' and then the various shadowing local
'fdc' variables (or function arguments).

Mind adding that too? Slightly less automatic, I agree, because then
you really do have to disambiguate between the "is this the shadowed
use of a local 'fdc'" case or the "this is the global 'fdc' use" case.

Can coccinelle do that?

                Linus