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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.