Re: Clarifying confusion of our variable placement rules caused by cleanup.h

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2025-11-18 at 17:34 -0500, Steven Rostedt wrote:
> On Tue, 18 Nov 2025 16:10:00 -0500
> James Bottomley <James.Bottomley@HansenPartnership.com> 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?

Well yes, that was the difference.

> 	{
> 		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.

But how would that be different from a declaration scope with the
declarations at the top?  In many ways that's precisely what for (int
i=0 ...) is except we don't have a generic way of doing it as a block
prefix statement for a bunch of variables.

Regards,

James