Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Brett 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: References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <2024Aug30.195831@mips.complang.tuwien.ac.at> <2024Aug31.170347@mips.complang.tuwien.ac.at> <505954890d8461c1f4082b1beecd453c@www.novabbs.org> 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 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 >> > >