Re: Clarifying confusion of our variable placement rules caused by cleanup.h
Steven Rostedt <[email protected]>
| Newsgroups | dev.linux.lists.ksummit,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 18 Nov 2025 16:10:00 -0500 James Bottomley <[email protected]> wrote: > > > > { > > struct foo *var __free(kfree) = kmalloc(...) > > > > [...] > > > > return func(..., var); > > } > > > > It seems a bit strange to have the final return of a function from > > within an explicit scope block. > > Well, you did that ... the return could equally well have been outside > the block. However, I do think additional scoped blocks for variables > looks most readable when the scope of the variable is less than the > code on both sides. If the variable doesn't go out of scope until the > final return, I can see an argument for just doing an interior > declaration. I guess you mean by adding a ret value? { struct foo *var __free(kfree) = kmalloc(...) [...] ret = func(..., var); } return ret; As the var that is passed to the function that this function is retuning (tail call) is only scoped inside the brackets. But anyway, I don't plan on changing the code in question here. I do quite often use the scoped_guard() as that does document exactly what the guard is protecting. -- Steve