Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Fri, 11 Mar 2022 22:15:23 +0000
To:     Linus Torvalds <torvalds@linux-foundation.org>
From:   =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= <pobrn@protonmail.com>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Xiaomeng Tong <xiam0nd.tong@gmail.com>,
        Kees Cook <keescook@chromium.org>,
        Jakob Koschel <jakobkoschel@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>
Reply-To: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= <pobrn@protonmail.com>
Subject: Re: [RFC PATCH v1 1/2] list: add type-safer list_head wrapper
Message-ID: <1D4riYxukWActDG6uXJOjvSq0GvTWaO4KZGVfqmX5RG_HGGjzgBb3srCUNRZqyPOzzNzVIrKRw0ktupkVs0DWQGTiZ1cSuWEcu5z3O1Pk4Y=@protonmail.com>
In-Reply-To: <CAHk-=wg6PtRx9nBHVnrQkQkczGjXjO0E-oHXPPgPK_H+Nm=Czg@mail.gmail.com>
References: <20220311013238.3387227-1-pobrn@protonmail.com> <20220311013238.3387227-2-pobrn@protonmail.com> <CAHk-=wjkqz42CNjDgWA9U3uNWa9GriqaCqqKciqm0sZUYjfLQg@mail.gmail.com> <CAHk-=wjF4d_v5t=ht_vCOHxNDoPvsBuK-2jiEBus-__oPZuPFQ@mail.gmail.com> <wKlkWvCGvBrBjshT6gHT23JY9kWImhFPmTKfZWtN5Bkv_OtIFHTy7thr5SAEL6sYDthMDth-rvFETX-gCZPPCb9t2bO1zilj0Q-OTTSbe00=@protonmail.com> <CAHk-=wg6PtRx9nBHVnrQkQkczGjXjO0E-oHXPPgPK_H+Nm=Czg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi


2022. m=C3=A1rcius 11., p=C3=A9ntek 6:06 keltez=C3=A9ssel, Linus Torvalds =
=C3=ADrta:
> On Thu, Mar 10, 2022 at 6:49 PM Barnab=C3=A1s P=C5=91cze <pobrn@protonmai=
l.com> wrote:
> >
> > That is indeed a simpler thing to do, and doesn't need `offsetof()` at =
the
> > declaration, but there are places - not many -  where the `list_head` m=
ember
> > is inside a subobject, for example, so `member` now contains a period.
>
> Ahh, very true. And very annoying. So close, yet so far, and no way I
> can see to really deal with that.
>
> And it's not even really all that rare. It may not be the _common_
> case, but it's still fairly wide-spread and not some "one or two odd
> places" thing.
>
> This grep catches at least a subset of cases:
>
>     git grep '\<list_for_each_entry(.*\.[a-z_0-9]*)'
>
> and it's clearly all over.
>
> As mentioned, I don't think that we have had huge problems with
> getting the member name wrong. We do get a fair amount of checking in
> that it obviously has to be part of the type we iterate over, and even
> if you were to pick the wrong one, the result is a very simple "that
> doesn't work".
>
> But it would still undeniably be very nice to have some automatic
> build-time checking for it.
>

Yes, I think compile-time errors are significantly better than whatever you=
 get
at runtime. So, sorry to be this obtuse, but I gather the proposed interfac=
e
is a no-go in all ways, shapes, and forms in your eyes? I am fully aware th=
at it
does not magically solve everything and it does not work in the "interestin=
g"
and "convoluted" cases, but as mentioned in a previous email, I think there=
 are
still a lot of "boring" places where it can be used. But of course I don't =
want
to bother anyone if it's a definitive no.


> [...]


Regards,
Barnab=C3=A1s P=C5=91cze