Thread (38 messages) 38 messages, 2 authors, 2022-01-08

Re: [PATCH v11 09/15] iio: afe: rescale: reduce risk of integer overflow

From: Liam Beguin <hidden>
Date: 2021-12-22 19:59:07
Also in: linux-iio, lkml

On Wed, Dec 22, 2021 at 08:56:12PM +0200, Andy Shevchenko wrote:
On Wed, Dec 22, 2021 at 8:38 PM Liam Beguin [off-list ref] wrote:
quoted
On Wed, Dec 22, 2021 at 02:29:04PM +0200, Andy Shevchenko wrote:
quoted
On Wed, Dec 22, 2021 at 5:47 AM Liam Beguin [off-list ref] wrote:
...
quoted
quoted
quoted
-               tmp = 1 << *val2;
At some point this should be BIT()
Forgot to add, If it's 64-bit, then BIT_ULL().
quoted
I'm not against changing this, but (to me at least) 1 << *val2 seems
more explicit as we're not working with bitfields. No?
You may add a comment. You may use int_pow(), but it will be suboptimal.
quoted
quoted
Rule of thumb (in accordance with C standard), always use unsigned
value as left operand of the _left_ shift.
Right, that makes sense! In practice though, since we'll most likely
never use higher bits of *val2 with IIO_VAL_FRACTIONAL_LOG2, would it be
enough to simply typecast?

        tmp = 1 << (unsigned int)*val2;
No, it's about the _left_ operand.
I haven't checked if tmp is 64-bit, then even that would be still wrong.
Okay so your recommendation is to not use a left shift?

I can look into that but given how unlikely it is to fall into those bad
cases, I'd rather keep things as they are. Would that be okay?

Also, I don't think using BIT() or BIT_ULL() would address this as they
both do the same shift, with no extra checks.

Cheers,
Liam
-- 
With Best Regards,
Andy Shevchenko
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help