OberonCore

Намедни ради интереса перекомпилировал Блэкбокс с опцией allchecks (включить все проверки).
Результат попытки запуска Блэкбокс после этого можно посмотреть на скриншоте.
Сразу оговорюсь, что я работаю с эксклюзивной неофициальной сборкой Блэкбокс, которая получена из локализованной версии 1.5.
В связи с этим вопрос: может ли кто-нибудь повторить этот опыт с официальной сборкой Блэкбокс? И если результат будет аналогичным, то хотелось бы услышать какой-нибудь комментарий по этому поводу.
Если же ваш опыт будет успешным, то я буду знать, что у меня проблема с "out of range" из-за того, что я "влез", так сказать, в исходники

PS. Да, если опцию allchecks не включать,то всё работает хорошо и проблем не возникает.

Проверил сам, на версии 1.5.
К счастью, оказалось проблемы у меня. Так что остальные пользователи Блэкбокс могут быть спокойны.
Честно говоря, было бы странно, если бы было иначе. Среда достаточно зрелая, без малого 20 лет - это срок. Ну, а для меня впредь будет наука: если вносишь серьёзные изменения, то включай все проверки. По умолчанию опция allchecks отключена.

А хорошая задача -- добиться тут нормальной работы.

Дальше ещё интереснее. Стал искать багу, оказалось что проблема даже не в моей эксклюзивной сборке Блэкбокс, а в компиляторе командной строки, который я использую. Но работу над ним я ещё не закончил, так что обнаружил "фифект" очень вовремя. Жаль вот только, что обнаружил случайно. А должно быть закономерно. В пору поглубже поразмышлять о пользе доказательного программирования

Продолжил поиск ошибки. К сожалению, мой предыдущий вывод о том, что виноват не Блэкбокс, а мой компилятор, оказался ошибочным.
Оставим пока в покое мою потенциально бажную эксклюзивную сборку Блэкбокс вместе с моим компилятором. Как я понимаю, они не вызывают прилива доверия у публики
Я проверил официальные версии v1.5 Eng и v1.6rc5 Eng, а также нашу русскую локализованную версию от 19.01.2008 r116. Во всех случаях трабла подтвердилась.

Для всех желающих предлагаю проделать следующий опыт:
1. Скопируйте содержимое рабочей папки Блэкбокс во временную директорию. Далее работать только в ней.
2. Запустите Блэкбокс. Откройте модуль DevCompiler и отредактируйте его. Найдите костанту defopt (опции компилятора по умолчанию) и добавьте в неё опцию allchecks. Сохраните изменения и перекомпилируйте модуль.
3. Выгрузите модуль DevCompiler. (Очень важный пункт. Первый раз я его не выполнил и в результате сделал неправильный вывод -- см. мои посты выше).
4. Перекомпилируйте все модули Блэкбокс при помощи команды DevCompiler.CompileThis. Закройте Блэкбокс.

Очевидно, что после этих манипуляций наш Блэкбокс будет выполнять проверку на переполнение и выход за диапазон (см. модуль DevCPC486). Конфуз однако состоит в том, что Блэкбокс эти проверки не проходит уже при запуске. Либо сами проверки выполняются некорректно.

Вывод, который я только что сделал, представляется мне не правдоподобным. Может я всё-таки что-то напутал. Прошу вывести на чистую воду.

PS: Смутные подозрения у меня вызывает реализация стандартных функций CHR и ORD. Более точно ничего сказать пока не могу, ошибку (предположительно! ) обнаружил только сегодня.

А! Сразу не понял. Тут речь, видимо, о переполнении целых. Дело сомнительное. В смысле сомнительно, нужно ли требовать проверки переполнений в ран-тайм. Хотя я склонен был бы закручивать все гайки, но тут может оказаться геморрой. Не знаю.

Так и есть.
При работе с символами как с байтами возникает переполнение. TextModels, например, тоже вылетает на WriteSChar.

От приложений зависит. В некритических областях, не связанных с человеческими жизними это переполнение - пофигу.
Ну возникнет ошибка, ну исправят...
Правда, при расчете зарплаты - это тоже критично...

Всем спасибо за наводочки! Как станет посвободнее со временем буду посмотреть
Думаю, что имеет смысл включать эти проверки во время тестовых прогонов на заключительном этапе работы над проектом, перед выпуском программного продукта. Убедиться, что всё нормально, ну а Release делать уже без них.

Можно отдельные особо критичные модули всегда компилировать с полными проверками.

Не доделаная статья в вики касательно опций компиляции: http://oberoncore.ru/wiki/blackbox/%D1% ... 1%80%D0%B0

... используя, например, функцию DevCompiler.CompileOpt(). Для включения всех проверок служит метасимвол "+".

Или, что более удобно, DevCompiler.CompileThis {Модуль[опции]}. Символы опций посмотреть в CompileOpt, там виднее всего... igor, раз Вы этим вопросом интересуетесь, не хотите принять участие в улучшении статьи в вики (см http://oberoncore.ru/wiki/about)?

Похоже, что мы имеем дело со вторым случаем. То есть ошибка относится к классу "Ложная тревога".

Попутно обнаружил ещё одну ошибочку, которую можно отнести к классу "Пропуск аварии", а это считается посерьёзнее. Глаза резанул следующий фрагмент кода в модуле DevCPC486: Понятно, что в одном из двух вызовов функции Check() верхняя граница диапазона указана неправильно. Для того чтобы выяснить в каком именно, находим нужную строчку в теле процедуры Check(): Как видим проверяется условие ccBE (меньше или равно), значит фактический параметр 255 указан правильно, а вместо 65536 следует писать 65535. Эта ошибка имеет два вхождения в указанном модуле.

Отписал в личку