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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 16 Jan 2017 11:40:59 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     Eric Paris <eparis@...hat.com>,
        linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
        Eric Paris <eparis@...isplace.org>,
        James Morris <james.l.morris@...cle.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        William Roberts <william.c.roberts@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 00/46] SELinux: Fine-tuning for several function implementations

On Mon, Jan 16, 2017 at 10:26 AM, Eric Paris <eparis@...hat.com> wrote:
> <opinion from irrelevant person>

Well, not totally irrelevant, I just reserve the right to ignore Eric
if I disagree with him ;)

> All of the patches look good to me except most of those which change
> the handling of `rc=`. I have a personal style preference for
>
> rc = -ENOMEM;
> val = kalloc();
> if (!val)
>   goto err;
>
> vs
>
> val = kalloc();
> if (!val) {
>   rc = -ENOMEM;
>   goto err;
> }
>
> because it saves 1 line and I think the compiler does the right/same
> thing. If there is preference among the people active in selinux
> developers (like I said, I'm now irrelevant) I guess they win.

My preference tends to be the other way around; I think putting the rc
assignment in the if block makes the code more readable and that is
how I tend to write things.  That said, I don't recall ever requiring
someone to redo a patch only because of this style nit ... if I did,
shame on me.

> But certainly a big +1 from me for the array allocation and sizeof()
> changes.

I do appreciate all the patches, thank you!  However, a bit of a
warning that it may take me a little bit of time to work my way
through reviewing and merging all of them.

-- 
paul moore
www.paul-moore.com

Powered by blists - more mailing lists