Здравствуйте, netch80, Вы писали:

N>В современных процессорах, как правило, деление на 0 или деление с переполнением не вызывает исключения

И это очень странно. Из каких соображений это делается?

N>RISC-V обещает, что беззнаковое деление на 0 даст ~0 (как UINT_MAX).

Такой подход ломает одно из основных свойств целочисленного деления (модуль частного не больше модулей делимого и делителя).

N>Язык может генерировать исключение на это или подставлять такой же безопасный дефолт.

В чем "безопасность" такого дефолта? Вот имеем байтовое смещение, делим на размер элемента, ожидаем получить индекс элемента. Вместо размера по ошибке делим на нуль, получаем UINT_MAX, применяем в качестве индекса. В соседней теме

Автор: Shmj
Дата: 21.09 07:39

смотрим, какая доля участников высказалась против автоматической вставки проверок индексов. Какую перспективу имеем?

N>Если исключение отражается в видимой диагностике, это можно было бы написать.

N>вообще подход, что не предполагается обрабатывать ошибки в арифметике, потому что нет возможности их отобразить в результате операции.

Почему нет? Или предусмотреть перехват возможного исключения, или проверить операнд(ы) перед выполнением операции.

N>Ты не знаешь, что там точно было.

Почему? Я точно знаю, что система переставала загружаться.

N>Я не знаю, что там точно было.

N>Потом кто-то другой в другом месте перевёл запрос доступной памяти на использование вызова B-15E801, который способен отдать к нему дополнительно "DX = configured memory above 16M, in 64K blocks", соответственно до 4GB, а код в построителе таблиц для пейджинга просто не обновили соответственно.

А можно было просто иметь одну функцию вроде GetMemorySize, которая определяет объем памяти любым удобным образом, тогда и части кода согласовывать не придется.

N>использовать тотальный defensive programming между собственными микро-компонентами в пределах одной службы... как по мне, это избыточно в 99.99% случаев, толку нет.

В ортогональности и унификации всегда есть толк.