Re: What is your opinion about unsigned int u = -2 ?

On 02/08/2024 16:48, Bart wrote:

On 02/08/2024 15:33, Kenny McCormack wrote:

In article <v8inds$2qpqh$1@dont-email.me>,
Thiago Adams  <thiago.adams@gmail.com> wrote:
...

So it seams that anything is ok for unsigned but not for signed.
Maybe because all computer gave same answer for unsigned but this is not
true for signed?

>
I think it is because it wants to (still) support representations other
than 2s complement.  I think POSIX requires 2s complement, and I expect the
C standard to (eventually) follow suit.
>

 C23 assumes 2s complement. However overflow on signed integers will still be considered UB: too many compilers depend on it.
 But even if well-defined (eg. that UB was removed so that overflow just wraps as it does with unsigned), some here, whose initials may or may not be DB, consider such overflow Wrong and a bug in a program.
 However they don't consider overflow of unsigned values wrong at all, simply because C allows that behaviour.
 But I don't get it. If my calculation gives the wrong results because I've chosen a u32 type instead of u64, that's just as much a bug as using i32 instead of i64.
 

You don't get it because you never pay attention to what I write - you'd rather jump to conclusions without reading.
In almost all cases, wrapping signed integer overflow would give the incorrect (in terms of what makes sense for the code) result even if it is fully defined by the compiler.
In almost all cases, wrapping unsigned integer overflow would give the incorrect (in terms of what makes sense for the code) result regardless of the fact that C gives a definition for the behaviour.
There are, of course, exceptions - situations where you really do want modulo arithmetic.  But in most cases you want integer types that model real mathematical integers to the extent possible with efficient practical implementations.  Using 16-bit int because the numbers are easier, if you have 65535 apples in a pile and you add an apple, you do not expect to have 0 apples.  That would be almost as silly as having 32767 apples, adding one more, and having -32768 apples.
Outside of the occasional rare case, code that relies on overflow behaviour of integers - signed or unsigned, defined by the language/implementation or not - is logically incorrect code.
That is in addition to some cases (signed integer overflow for C) being undefined in the language.
It's helpful that the language provides a way to get modulo arithmetic for the cases that need it.  But just because C defines the behaviour of unsigned integer overflow, does not make it makes sense in code. Defined incorrect results are just as wrong as undefined incorrect results.