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

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

On Tue, 2025-11-18 at 15:51 -0500, Steven Rostedt wrote:
> On Tue, 18 Nov 2025 15:21:10 -0500
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > There is one last case that hasn't been discussed, which is where
> > you deliberately introduce an extra scope block for the free and
> > allocation, so in your example above it would look like
> > 
> > 	if (ret < )
> > 		return -ERROR
> > 
> > 	[ several more error exits ]
> > 
> > 	{
> > 		struct foo *var __free(kfree) = kmalloc(...)
> > 
> > 		[...]
> > 	}
> 
> I'm not too big on explicit blocks for just declarations. Especially,
> in my case where the var is used until the end:

Well I don't do it often, but there are times when the scope of a
variable is definitely a lot less than the scope of the code block.

I see this as being analagous to when you should use a guard vs a
scoped guard.

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

Regards,

James

>  Especially since the beginning is just for error conditions, and the
> meat of the function is now in that explicit block.
> 
> -- Steve
>