Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thiago Adams <thiago.adams@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: What is your opinion about unsigned int u = -2 ?
Date: Fri, 2 Aug 2024 22:03:51 -0300
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <v8jvln$33atp$1@dont-email.me>
References: <v8dfo9$1k7cg$1@dont-email.me>
 <pan$d2c8a$8c54ac9f$29a202e0$12c6ce86@invalid.invalid>
 <87bk2cecan.fsf@bsb.me.uk> <v8inds$2qpqh$1@dont-email.me>
 <v8iqnr$7l3c$1@news.xmission.com> <v8irje$2rolg$1@dont-email.me>
 <87r0b6g3qx.fsf@nosuchdomain.example.com> <v8jbj5$2us0r$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 03 Aug 2024 03:03:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6ca7cab00778520cac37785ddd7f8d1f";
	logging-data="3255225"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/u4VGQFEHAi6zCwiZvL/pjrTuTq+7+6/k="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:FvkKQAA/A5Ld683Jv5AeySYhEms=
In-Reply-To: <v8jbj5$2us0r$4@dont-email.me>
Content-Language: en-GB
Bytes: 3510

Em 8/2/2024 4:21 PM, James Kuyper escreveu:
> 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.
> 

I am doing experiments with constexpr. What happens with overflow in 
compile time? The answer is not so clear. Sometimes it does not compile 
and sometimes it works as in runtime.

constexpr int i = 1073741823;
constexpr int i2 = i*3/3;  /*does not compile*/

But this compiles and outputs

#include <stdio.h>

int main()
{
     constexpr signed char i = -2;
     constexpr unsigned long long u = 0ull+i;
     printf("%ull", u); /*prints 4294967294*/
}