Message-ID: <CAHk-=wiCOTW5UftUrAnvJkr6769D29tF7Of79gUjdQHS_TkF5A@mail.gmail.com>
Date: Tue, 18 Nov 2025 10:38:20 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bart Van Assche <bvanassche@....org>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>, ksummit@...ts.linux.dev, 
	Dan Williams <dan.j.williams@...el.com>, linux-kernel <linux-kernel@...r.kernel.org>, 
	Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: Clarifying confusion of our variable placement rules caused by cleanup.h

On Tue, 18 Nov 2025 at 09:25, Bart Van Assche <bvanassche@....org> wrote:
>
> A related question is whether or not to allow declarations in the
> initialization expression of for-statements.

Absolutely. It's *such* an improvement to the C syntax to be able to do

        for (int i = 0; i < x; i++)

both from a syntax and a variable lifetime rule.

It is also very much a "beginning of scope" syntax, even if the scope
isn't limited by a "{ }" grouping.

We already have that syntax being fairly widespread, doing a quick
grep for it shows over 3k uses of this ("int" being the most common,
but we've got other iterator types being used too).

So this is not even a question of "whether". It is already widely used.

The whole "declare variables in the middle of code" should still be
mostly frowned upon.

But it's practically required for cleanup situations - you really do
want the initialization to pair with the cleanup or you end up with
crazy code that might need dummy initialization that makes no sense.

And I think that is basically the only valid reason for it. The old
"declare at the top of scope" rule still holds true for normal
variable declarations so that you don't have to look for the types.

*MOST* of the cleanup cases are hopefully then abstracted out behind
various guard macros etc, where the declaration not only goes together
with the cleanup information, it's actually also a part of the whole
scoping rules for cleanup.

But the whole "only declare at the top" really doesn't work well for
automatic cleanup. I do see some people still adhering to that rule,
but it really can result in odd looking code. You end up with things
like this:

        struct x509_parse_context *ctx __free(kfree) = NULL;
        ... other code ...
        ctx = kzalloc(sizeof(struct x509_parse_context), GFP_KERNEL);

where you have now split up the whole "this is allocated by kmalloc,
and free'd by kfree" into two different sections that are not next to
each other.

And while I still don't love the "declare variables in the middle of
random code" and I think we're better off with the old rule of
generally declaring things at the top of scope, I really do think that
it's better to keep the freeing-vs-allocation logic together.

Side note: there are other situations where we might just want to
admit that sometimes it's better to declare at the point where the
first variable assignment is done. In particular, when using automatic
types, the type obviously comes from the assignment. So you have a
similar situation wrt the whole declaration location: if you use an
auto type, you can't declare things separately from the assignment -
and the assignment might not work at the top of a scope.

So I do suspect that I'll just have to get used to assignments in the
middle of code in general, but I feel we want to limit it to the cases
where there is a real reason for why the declaration needs to be in a
particular place.

Example automatic type thing: something like this

    #define kmalloc_type(type,gpf) (type *)kmalloc(sizeof(type),gpf)

    __auto_type x = kmalloc_type(struct mystruct);

simply doesn't work if you don't allow the declaration in the middle
of code, because assignments invariably will sometimes be after other
code.

Now, we currently don't use __auto_type very much outside of macros
(and there we often use "typeof(x)" instead for historical compiler
reasons), but I suspect we probably should.  There's a patch floating
around that makes it more convenient with a

   #define auto __auto_type

because the historical C 'auto' keyword has been so completely and
utterly useless.

                  Linus

Powered by blists - more mailing lists