Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 4 Sep 2024 18:34:29 +0200
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <vba26l$3te44$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me>
 <vb91e7$3o797$1@dont-email.me> <vb9eeh$3q993$1@dont-email.me>
 <vb9l7k$3r2c6$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 18:34:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="007bf4bb57fea4fb73ad9dc6d5dccf66";
	logging-data="4110468"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Dlxy6srhERq/LF64sGl1UDJ2Rr5V4pvM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:bFmJDWG7uI7JIhiqhYide94B7cE=
In-Reply-To: <vb9l7k$3r2c6$2@dont-email.me>
Content-Language: en-GB
Bytes: 3725

On 04/09/2024 14:53, jseigh wrote:
> On 9/4/24 06:57, David Brown wrote:
>> On 04/09/2024 09:15, Terje Mathisen wrote:
>>> David Brown wrote:
> 
>>> Maybe?
>>>
>>> Rust will _always_ check for such overflow in debug builds, then when 
>>> you've determined that they don't occur, the release build falls back 
>>> standard CPU behavior, i.e. wrapping around with no panics.
>>
>> But if you've determined that they do not occur (during debugging), 
>> then your code never makes use of the results of an overflow - thus 
>> why is it defined behaviour?  It makes no sense.  The only time when 
>> you would actually see wrapping in final code is if you hadn't tested 
>> it properly, and then you can be pretty confident that the whole thing 
>> will end in tears when signs change unexpectedly.  It would be much 
>> more sensible to leave signed overflow undefined, and let the compiler 
>> optimise on that basis.
>>
> 
> You absolutely do want defined behavior on overflow. 

No, you absolutely do /not/ want that - for the vast majority of use-cases.

There are times when you want wrapping behaviour, yes.  More generally, 
you want modulo arithmetic rather than a model of mathematical integer 
arithmetic.  But those cases are rare, and in C they are easily handled 
using unsigned integers.

You can't use signed integers for them in C (except of course if you use 
explicit modulo and none of your intermediary results overflow int), 
because signed integer overflow is UB.  You can't use signed integers 
for the purpose in Rust either, even though it is defined behaviour in 
release mode, because it is a run-time error in debug mode.  (That's why 
Rust's attitude here is completely daft to me.)

> There are
> algorithms that depend on that.  Bakery algorithms for instance.
> Unless you think a real life bakery with service tickets
> numbering from 1 to 50 either never gets more than 50 customers
> in a day or closes after their 50th customer. :)
> 
> Joe Seigh
>