Здравствуйте, Евгений Музыченко, Вы писали:

N>>видимый размер ATA дисков обрезался до остатка от деления на 32GB.
N>>в целом сам стиль кодирования на C/C++ провоцирует на такие ошибки.
ЕМ>Да ладно. В каком языке есть хоть какая-то защита от неправильного применения хоть деления с остатком, хоть обычного деления?

Смотря что считать защитой и что — языком.

В современных процессорах, как правило, деление на 0 или деление с переполнением не вызывает исключения. RISC-V обещает, что беззнаковое деление на 0 даст ~0 (как UINT_MAX).

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

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

ЕМ>С 480 Мб для Win 95 косяк был не в том, что выбрали фиксированный разумно достаточный размер пула, а то, что вместо игнорирования "лишней" памяти получился отказ в загрузке всей системы. Если и ставился вопрос "а вдруг памяти окажется до хренища?", то ответ "в таком случае надо выйти из ситуации корректно" явно не фигурировал.

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

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

Вот тебе вариант совершенно навскидку, но для меня выглядит правдоподобно: сначала код получал объём памяти через вызов B-1588. Тот отдаёт килобайты после 0x100000 в AX, соответственно, предел в 64MB (плюс 640KB). Они заточились чуть наперёд на то, что его можно расширить, например, до 256MB, если кто-то отрапортует новыми средствами, и соответственно рассчитали размеры таблиц. Потом кто-то другой в другом месте перевёл запрос доступной памяти на использование вызова B-15E801, который способен отдать к нему дополнительно "DX = configured memory above 16M, in 64K blocks", соответственно до 4GB, а код в построителе таблиц для пейджинга просто не обновили соответственно. Оно выдержало и 256MB, и много следующих размеров типа 384MB, но на 480MB стало падать.

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

Если возражаешь — покажи код. Я подозреваю, что код старта Windows 95 где-то давно утёк, только я, увы, в существующих утечках видел только сильно более поздние версии. Пока кода нет — обсуждать дальше нет смысла.