Сообщение Re[9]: Откуда такая неизбывная приверженность к константам? от 23.10.2024 9:33
Изменено 23.10.2024 9:34 netch80
Re[9]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
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 где-то давно утёк, только я, увы, в существующих утечках видел только сильно более поздние версии. Пока кода нет — обсуждать дальше нет смысла.
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 где-то давно утёк, только я, увы, в существующих утечках видел только сильно более поздние версии. Пока кода нет — обсуждать дальше нет смысла.
Re[9]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
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 где-то давно утёк, только я, увы, в существующих утечках видел только сильно более поздние версии. Пока кода нет — обсуждать дальше нет смысла.
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 где-то давно утёк, только я, увы, в существующих утечках видел только сильно более поздние версии. Пока кода нет — обсуждать дальше нет смысла.