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  linux-cve-announce  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:   Sun, 29 Oct 2017 12:50:37 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eugeniu Rosca <erosca@...adit-jv.com>,
        Kazuya Mizuguchi <kazuya.mizuguchi.ks@...esas.com>,
        Masaru Nagai <masaru.nagai.vx@...esas.com>,
        Niklas Söderlund 
        <niklas.soderlund+renesas@...natech.se>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Simon Horman <horms+renesas@...ge.net.au>,
        Yuval Shaia <yuval.shaia@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: Re: [PATCH] ravb: Use common error handling code in ravb_probe()

>> @@ -2069,10 +2069,9 @@ static int ravb_probe(struct platform_device *pdev)
>>                 irq = platform_get_irq_byname(pdev, "ch22");
>>         else
>>                 irq = platform_get_irq(pdev, 0);
>> -       if (irq < 0) {
>> -               error = irq;
>> -               goto out_release;
>> -       }
>> +       if (irq < 0)
>> +               goto failure_indication;
> 
> IMHO, it's really confusing that "irq" contains the error code, not "error".
> Especially when jumping to a meaningless label named "failure_indication"
> ("irq_failure" would be more intuitive).

Thanks for your constructive feedback.


> So I prefer the original code, regardless of the label name.

Can another attempt make sense to concentrate the setting of a variable
at the end of this function with more pleasing identifiers?

Regards,
Markus

Powered by blists - more mailing lists