linux-kernel - Re: [PATCH] iio: light: gp2ap020a00f: Fix signedness bug in gp2ap020a00f_get_thresh

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] [day] [month] [year] [list]

Message-ID: <20251231171545.2231c7c2@jic23-huawei>
Date: Wed, 31 Dec 2025 17:15:45 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Alper Ak <alperyasinak1@...il.com>, David Lechner
 <dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>, Andy
 Shevchenko <andy@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: light: gp2ap020a00f: Fix signedness bug in
 gp2ap020a00f_get_thresh_reg()

On Sat, 27 Dec 2025 17:00:46 +0200
Andy Shevchenko <andriy.shevchenko@...el.com> wrote:

> On Fri, Dec 26, 2025 at 06:45:21PM +0300, Alper Ak wrote:
> > gp2ap020a00f_get_thresh_reg() returns -EINVAL on error,
> > but it was declared as a u8.
> > 
> > Change the return type to int and update callers to use int type for
> > the return value and properly check for negative error codes.  
> 
> ...
> 
> >  	thresh_reg_l = gp2ap020a00f_get_thresh_reg(chan, dir);  
> 
> > +  
> 
> This blank line is redundant.
> 
> > +	if (thresh_reg_l < 0) {
> > +		err = thresh_reg_l;
> > +		goto error_unlock;
> > +	}  
> 
> And entire code can be rewritten in a shorter way
> (in this case the type not needed to be changed):
> 
> 	err = gp2ap020a00f_get_thresh_reg(chan, dir);
> 	if (err < 0)
> 		goto error_unlock;
> 	thresh_reg_l = err;
> 
> but this one is up to maintainers as I know Jonathan likes the clear naming
> to be assigned to (however when written as above it clear to me what's the
> semantics of the non-negative returns).

This pattern is absolutely fine.  I don't mind using an err, ret or similar
briefly like this as the real meaning of the successful value is right there
2 lines down

Jonathan

> 
> ...
> 
> Ditto for the other function.
>