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:12:04 -0300
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <v8k055$33fcl$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>
 <v8jvln$33atp$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 03 Aug 2024 03:12:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6ca7cab00778520cac37785ddd7f8d1f";
	logging-data="3259797"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18fAhWxYt6LTZsi9mnNqGLzp16OaLjiflY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:t44/+AFzy8pA9zEXm548uGUH4RA=
In-Reply-To: <v8jvln$33atp$1@dont-email.me>
Content-Language: en-GB
Bytes: 3897

Em 8/2/2024 10:03 PM, Thiago Adams escreveu:
> 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*/
> }
> 

It is interesting to compare constexpr with the existing constant 
expression in C that works with integers.Compilers extend to work with 
unsigned long long.
constexpr works with the sizes as defined , for instance char.