Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Brett <ggtgp@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 4 Sep 2024 20:31:24 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <vbag2s$3vhih$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>
 <vba26l$3te44$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 22:31:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="59148afa0b64ac6c8e93bd21d62f7adc";
	logging-data="4179537"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/fkylpbyAa3OcVI8EY7NkO"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:L+rjOOuieJedlQy1mjqbq4LuixQ=
	sha1:qeKFdtVIXvDhiEU+OSuvNGfSz7E=
Bytes: 4132

David Brown <david.brown@hesbynett.no> wrote:
> 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.

I tried using unsigned for a bunch of my data types that should never go
negative, but every time I would have to compare them with an int somewhere
and that would cause a compiler warning, because the goal was to also
remove unsafe code.

Complete and udder disaster, went back to plain sized ints.

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