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

Em 8/3/2024 2:34 PM, David Brown escreveu:

On 02/08/2024 21:21, James Kuyper wrote:

On 8/2/24 14:48, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:
[...]

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.

>
There is a difference in that unsigned "overflow" might give
(consistent) results you didn't want, but signed overflow has undefined
behavior.

>
When David was expressing the opinion Bart is talking about above, he
was talking about whether it was desirable for unsigned overflow to have
undefined behavior, not about the fact that, in C, it does have
undefined behavior. He argued that signed overflow almost always is the
result of a logical error, and the typical behavior when it does
overflow, is seldom the desired way of handling those cases. Also, he
pointed out that making it undefined behavior enables some convenient
optimizations.
>
For instance, the expression (num*2)/2 always has the same value as
'num' itself, except when the multiplication overflows. If overflow has
undefined behavior, the cases where it does overflow can be ignored,
permitting (num*2)/2 to be optimized to simply num.
>

 Yes, that is all correct.
 IMHO - and I realise it is an opinion not shared by everyone - I think it would be best for a language of the level and aims of C to leave all integer overflows as undefined behaviour.  It is helpful for implementations to have debug or sanitizing modes that generate run-time checks and run-time errors for overflows, to aid in debugging.  (clang and gcc both provide such features - no doubt other compilers do too.)
 And you do need additional features to get modulo effects on the occasions when these are needed.  I think you could come a long way with the ckd_ macros from C23 :
 #include <stdckdint.h>
bool ckd_add(type1 *result, type2 a, type3 b);
bool ckd_sub(type1 *result, type2 a, type3 b);
bool ckd_mul(type1 *result, type2 a, type3 b);
  (Of course, C is the way it is, for many reasons - and I am not suggesting it be changed!)
 

Consider this sample
#include <stdio.h>
#define MINUSONE -1
int main(){
   unsigned int a = 0;
   unsigned long long b = 0;
   unsigned long long r ;
   r = a + MINUSONE; /*4294967295*/
   printf("%llu\n", r);
   r = b + MINUSONE;
   printf("%llu\n", r); /*18446744073709551615*/
}
We have a invisible conversion from -1 to  unsigned int or  unsigned long long. The value used at the expression is not -1.
I think I will add a warning in cake for this situation. A cast can remove the warning.
For instance
r = a + ((unsigned long)MINUSONE);