Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: comp.arch Subject: Re: is Vax addressing sane today Date: Mon, 23 Sep 2024 17:51:26 -0400 Organization: A noiseless patient Spider Lines: 48 Message-ID: References: <09ce1622b872f0b0fa944e868a8c97be@www.novabbs.org> <2024Sep10.094353@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Mon, 23 Sep 2024 23:51:29 +0200 (CEST) Injection-Info: dont-email.me; posting-host="4b01e9bc3f3192bb258d057b1367074c"; logging-data="3025851"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18WtN4Hau5EXkjttxzV2mtovZ9OdoNl2IQ=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:BiMG1/kheAdP/RhmVQvCGJPPduQ= sha1:Ecxbt/PCPHRVbVQrXuGNEHfAMb8= Bytes: 3465 > Let's look at how you might want to handle overflows when they happen: > > 1) Your language supports seemlessly transitioning to BigInts on > overflow. Then each operation that could overflow needs to call > a special bit of code to change to BigInt and then continue the > calculation. This code must exist, even if a trapping > instruction doesn't need an explicit branch to it. Some > mechanism is needed to call this code. IOW, this is the case where the program thinks it's manipulating some "mathematical number ∈ Z" or something like it. > 2) You need to call an exception handler, and the routine with the overflow > is ended. We need to know which exception handler to call. Not sure when that would be useful, other than for low-level coding. > 3) You want to clamp the value to a reasonable range and continue. The > reasonable values need to be looked up somewhere. Here overflow detection can be useful only to the extent that the wrap-around may hide the range-error (or confuse its nature between over<->under). I'm not familiar with code needing this, but I heard such needs are common in some fields. > 4) You just want to crash the program. If a debugger is attached, it can > say where the overflow occurred. Beside debugging, this corresponds to the case where the code thinks it's manipulating some "mathematical number ∈ Z" or something like it yet we have a good reason to think that this number will "never" overflow, so we never want to switch to bigint because an overflow means our "good reason" was crap and we we're in trouble anyway. IME, this shows up typically for integers related to the size of some data-structure, where the limited address space "guarantees" that we'll never go beyond some limit. They're *very* common (think array indices and things like that) and using overflow-trapping operations for them would make sense. At the same time, they *should* never overflow, and if some error somewhere means one of them can overflow (e.g. mistakenly using (u)int32 for array indices in a 64bit system), there's a good chance that the error will cause other trouble which may prevent us from even reaching the overflowing operation. Stefan