On Fri, Aug 02, 2024 at 02:59:46PM +0100, Jonathan Cameron wrote:
> On Thu, 1 Aug 2024 20:26:31 +0300
> Leon Romanovsky <leon@xxxxxxxxxx> wrote:
>
> > On Thu, Aug 01, 2024 at 09:58:29AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Jul 30, 2024 at 11:00:38AM +0300, Leon Romanovsky wrote:
> > > > > +
> > > > > + void *inbuf __free(kvfree) =
> > > > > + kvzalloc(cmd->in_len, GFP_KERNEL | GFP_KERNEL_ACCOUNT);
> > > >
> > > >
> > > > <...>
> > > >
> > > > > + out_len = cmd->out_len;
> > > > > + void *outbuf __free(kvfree_errptr) = fwctl->ops->fw_rpc(
> > > > > + ucmd->uctx, cmd->scope, inbuf, cmd->in_len, &out_len);
> > > >
> > > > I was under impression that declaration of variables in C should be at the beginning
> > > > of block. Was it changed for the kernel?
> > >
> > > Yes, the compiler check blocking variables in the body was disabled to
> > > allow cleanup.h
> > >
> > > Jonathan said this is the agreed coding style to use for this
> >
> > I'm said to hear that.
>
> Was passing on a statement Linus made (not digging it out right now)
> that he really wanted to be able see constructors and destructors
> together.
The thing is that we are talking about the same thing. I and Linus want
to keep locality of variables declaration and initialization. I don't
know the Linus's stance on it, but I'm sad that to achieve that for
cleanup.h, very useful feature of GCC (keep variables at the beginning
of the block) was disabled.
Right now, you can declare variables in any place and it is harder to
review the code now. It is a matter of time when we will see code like
this and start to chase bugs introduced by this pattern:
int f()
{
<some code>
int i;
<some code>
return something;
}
Thanks
>
> The other part is that in some cases you can end up with non
> obvious ordering bugs because the cleanup is the reverse of the
> declarations, not the constructors being called.
> Whilst it is fairly easy to review for this, future code reorganization
> may well lead to subtle bugs, typically in error paths etc.
>
> Putting the declaration inline avoids this potential problem
>
> Dan wrote a style guide proposal.
> https://lore.kernel.org/all/171175585714.2192972.12661675876300167762.stgit@xxxxxxxxxxxxxxxxxxxxxxxxx/
> [PATCH v3] cleanup: Add usage and style documentation
>
> seems it died out without anyone applying it. I've poked.
>
> Jonathan
>
> >
> > Thanks
> >
> > >
> > > Jason
> >
>
>
