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:17:19 +0200
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <v8lon1$3hv78$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 03 Aug 2024 19:17:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="45df3032d4968d93b02cc20e1294d76e";
	logging-data="3734760"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5P30shYeCO/cnVkSQiTTA7o4HKrZXvzs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:oLIIyVT4acyTt09WlLLCjcF4lrQ=
Content-Language: en-GB, nb-NO
In-Reply-To: <v8irje$2rolg$1@dont-email.me>
Bytes: 4029

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.