lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 16 Aug 2020 10:00:46 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Luis Henriques <lhenriques@...e.de>,
        David Laight <David.Laight@...LAB.COM>
Cc:     Ilya Dryomov <idryomov@...il.com>,
        "ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ceph: remove unnecessary return in switch statement

On Fri, 2020-08-14 at 11:03 +0100, Luis Henriques wrote:
> David Laight <David.Laight@...LAB.COM> writes:
> 
> > From: Luis Henriques
> > > Sent: 14 August 2020 10:38
> > > 
> > > Since there's a return immediately after the 'break', there's no need for
> > > this extra 'return' in the S_IFDIR case.
> > > 
> > > Signed-off-by: Luis Henriques <lhenriques@...e.de>
> > > ---
> > >  fs/ceph/file.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> > > index d51c3f2fdca0..04ab99c0223a 100644
> > > --- a/fs/ceph/file.c
> > > +++ b/fs/ceph/file.c
> > > @@ -256,8 +256,6 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> > >  	case S_IFDIR:
> > >  		ret = ceph_init_file_info(inode, file, fmode,
> > >  						S_ISDIR(inode->i_mode));
> > > -		if (ret)
> > > -			return ret;
> > >  		break;
> > > 
> > >  	case S_IFLNK:
> > 
> > I'd move the other way and just do:
> > 		return ceph_init_file_info(...);
> 
> Sure, that would work too, although my preference would be to have a
> single function exit point.  But I'll leave that decision to Jeff :-)
> 

I think I agree with Luis here (though it's really a bit subjective). I
don't think it'll matter much to the compiled result either way, and
that will probably be better if this function grows in complexity.

I'll plan to merge this patch in the next day or so.

Thanks!
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists