Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: jseigh <jseigh_es00@xemaps.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 4 Sep 2024 08:53:08 -0400
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <vb9l7k$3r2c6$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 14:53:08 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="54337a702529433b553e4ec243da3949";
	logging-data="4032902"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18/thB7W4cUNEu5xVyJmg8B"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Cn/juo5+8EgogJogOaxFPUJ/wk0=
Content-Language: en-US
In-Reply-To: <vb9eeh$3q993$1@dont-email.me>
Bytes: 2867

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. 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