Re: [PATCH v3 1/4] iio: prepare iio_format_value to handle higher-precision IIO_VAL_DECIMAL64_* formats

[David Laight <david.laight.linux@gmail.com>]

On Wed, 28 Oct 2026 10:11:05 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Tue, Oct 27, 2026 at 03:56:35PM -0300, Rodrigo Alencar wrote:
> > On 26/10/26 11:51, Victor Chernyakin wrote:  
> 
> +Cc: David Laight
> 
> ...
> 
> > > +/*
> > > + * Regular abs(LLONG_MIN) causes signed overflow, which is undefined
> > > + * behavior. This variant avoids that by performing the computation in an
> > > + * unsigned type, for which negation is always well-defined.
> > > + */
> > > +static inline u64 abs_s64_no_overflow(s64 x)
> > > +{
> > > +	return x < 0 ? -(u64)x : (u64)x;
> > > +}  
> > 
> > I think I've seen Andy doing mentions to a needed 'safe' abs() a couple of times.
> > Don't we have something in the tree already? if not, Why not adding a
> > 'unsigned' abs function to math.h? something like:  
> 
> Or maybe something clever using the s64/u64 domain for all.
> Let's gather David Laight's opinion.

Well, it might be UB, but that is probably mostly related to '1s compliment'
and 'sign overpunch' number schemes.
So, in practise (u64)(x < 0 ? -x : x) probably always gives the right answer.
The kernel is also compiled with -Wno-strict-overflow which also stops the
compiler doing unexpected things.
OTOH clang is know for 'silently just throwing away code' if it detects UB
behaviour, so code that is fine with variables can get miscompiled for
constants.
(All not helped by it being undefined behaviour, not undefined result.
And the 'behaviour' bit really being 'might trap'.)

This should work for all types (except s128 - not used in the kernel):
#define abs(x) ((x) >= 0 ? (x) : (u64)-((x) + 1) + 1)
or maybe the equivalent:
#define abs(x) ((x) >= 0 ? (x) : -((x) + 1) + 1ull)
which will generate the correct bit-pattern for s128.

The negate is always well defined and its result in non-negative.

gcc and clang also realise that the (u64) cast always zero extends
so can be optimised away for 32bit values (especially relevant for
32bit compiles).
Note that optimisation may not happen (I've not checked) if you use
a real function with an s64 argument.
(Which also has a downside if code passes a very large unsigned value.)

Oh, and the compilers realise the '+ 1' cancel out and throw them away.

David

> 
> > /**
> >  * uabs - return absolute value of an argument as an unsigned type
> >  * @x: the value.
> >  *
> >  * Unlike abs(), the result is well defined when @x is the minimum value of
> >  * a signed type, since the negation is done in the unsigned domain.
> >  *
> >  * Return: an absolute value of @x, as the unsigned counterpart of its type.
> >  */
> > #define uabs(x)	__uabs_choose_expr(x, long long,			\
> > 		__uabs_choose_expr(x, long,				\
> > 		__uabs_choose_expr(x, int,				\
> > 		__uabs_choose_expr(x, short,				\
> > 		__uabs_choose_expr(x, char,				\
> > 		__builtin_choose_expr(					\
> > 			__builtin_types_compatible_p(typeof(x), char),	\
> > 			({ signed char __x = (x);			\
> > 			   (unsigned char)(__x < 0 ? -(unsigned char)__x :	\
> > 						     (unsigned char)__x); }),	\
> > 			((void)0)))))))
> > 
> > #define __uabs_choose_expr(x, type, other) __builtin_choose_expr(	\
> > 	__builtin_types_compatible_p(typeof(x),   signed type) ||	\
> > 	__builtin_types_compatible_p(typeof(x), unsigned type),		\
> > 	({ signed type __x = (x);					\
> > 	   (unsigned type)(__x < 0 ? -(unsigned type)__x :		\
> > 				     (unsigned type)__x); }), other)  
>