Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Thomas Koenig Newsgroups: comp.arch Subject: Re: a bit of history, Stealing a Great Idea from the 6600 Date: Sat, 4 May 2024 10:08:57 -0000 (UTC) Organization: A noiseless patient Spider Lines: 16 Message-ID: References: <71acfecad198c4e9a9b14ffab7fc1cb5@www.novabbs.org> <2024May3.173347@mips.complang.tuwien.ac.at> Injection-Date: Sat, 04 May 2024 12:08:57 +0200 (CEST) Injection-Info: dont-email.me; posting-host="20df352177ed618ac09c61721b062ed9"; logging-data="1223752"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX185mLg4EL/tUP606aZFQbKMCQnYYgGoph8=" User-Agent: slrn/1.0.3 (Linux) Cancel-Lock: sha1:KeqvFX/pqP0gNEZeD/xSB1cYdvA= Bytes: 1670 John Levine schrieb: > It is my impression that > trapping on fixed point overflow is not very useful, and it's easier > to do a jump on overflow in the few cases where you care, or the x86 > INTO which you put after the arithmetic operaion to trap if the > overflow flag is set. Sanitzers would benefit greatly from trapping math. However, this could get into murky territory - to be really general, you would also need a version for trapping math with unsigned numbers. Just think of doing a unsigned loop with a lower bound that, due to some error in the code or input, has an upper bound of 0-1...