Deutsch   English   Français   Italiano  
<v8lq7i$3i56e$2@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: What is your opinion about unsigned int u = -2 ?
Date: Sat, 3 Aug 2024 19:43:14 +0200
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <v8lq7i$3i56e$2@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> <87h6c2fldh.fsf@nosuchdomain.example.com>
 <v8k21v$33nca$1@dont-email.me> <878qxefjk2.fsf@nosuchdomain.example.com>
 <v8k4i7$37tvs$1@dont-email.me> <87zfpue3bz.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 03 Aug 2024 19:43:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b209585f2ada3beb09365cfb8283ed97";
	logging-data="3740878"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/iAuZKhw2luCHpwq6uMp7RdrybSBLmxYE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:34+2rkAT0/iW18O/BM0OWS1sTqI=
Content-Language: en-GB, nb-NO
In-Reply-To: <87zfpue3bz.fsf@nosuchdomain.example.com>
Bytes: 4039

On 03/08/2024 04:40, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> [...]
>> Here a sample with signed int that has a overflow  warning.
>>
>>
>> #include <stdio.h>
>>
>> int main()
>> {
>>     constexpr int a = 2147483647;
>>     constexpr int b = 1;
>>     constexpr int c = a+b;
>> }
>>
>> https://godbolt.org/z/ca31r8EMK
> 
> It's reasonable to warn about a+b, since it has undefined behavior.
> In fact gcc warns about the expression a+b, since it has undefined
> behavior, and issues a fatal error message about its use in a context
> requiring a constant expression, since that's a constraint violation.
> 
>> I think both cases (overflow and wraparound) should have warnings.
> 
> You're free to think that, of course, but wraparound behavior is well
> defined and unambiguous.  I wouldn't mind an *optional* warning, but
> plenty of programmers might deliberately write something like
> 
>      const unsigned int max = -1;
> 
> with the reasonable expectation that it will set max to INT_MAX.
> 
>> Comparing with __builtin_add_overflow it also reports wraparound.
>>
>> #include <stdio.h>
>>
>> int main()
>> {
>>     unsigned int r;
>>     if (__builtin_add_overflow(0,-1, &r) != 0)
>>     {
>>       printf("fail");
>>     }
>> }
> 
> Of course __builtin_add_overflow is a non-standard gcc extension.  The
> documentation says:
> 
>   -- Built-in Function: bool __builtin_add_overflow (TYPE1 a, TYPE2 b,
>            TYPE3 *res)
>   ...
>       These built-in functions promote the first two operands into
>       infinite precision signed type and perform addition on those
>       promoted operands.  The result is then cast to the type the third
>       pointer argument points to and stored there.  If the stored result
>       is equal to the infinite precision result, the built-in functions
>       return 'false', otherwise they return 'true'.  As the addition is
>       performed in infinite signed precision, these built-in functions
>       have fully defined behavior for all argument values.
> 
> It returns true if the result is equal to what would be computed in
> infinite signed precision, so it treats both signed overflow and
> unsigned wraparound as "overflow".  It looks like a useful function, and
> if you use it with an unsigned target, it's because you *want* to detect
> wraparound.
> 

C23 provides ckd_add() that is identical to __builtin_add_overflow() 
except for the order of the operands.