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

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

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

DM>А что именно значит "ничего криминального"?
Я с теорией верифцирования не сильно знаком, но верификация и сейчас производится.

DM>Если программа делит единицу на миллиардный по счету бит числа пи, как верификатор поймет, что там деление на ноль?
Вряд ли, верификатор не будет арифметические ошибки ловить.

DM>Если идет обращение к массиву с нетривиально вычисляемым индексом, как верификатор угадает, нет ли выхода за пределы?
Это не верификатора работа, а реализации "массива", а верификатор удостоверится что реализация массива гарантирует что не будет обращения к памяти за пределами выделенной.

DM>Если идет загрузка модуля с вычисляемым именем и вызов функции из него, как статический верификатор узнает, что за функция будет вызвана?
А если не надо знать, ему достаточно знать что вызываемая функция тоже ничего "криминального" не делает.

DM>Возможности статической верификации настолько ничтожны, что я вообще с трудом представляю, от каких же вещей она способна защитить.
Это они в твоей голове ничтожны, а люди умудряются даже C_шый код верифицировать.
Смотри nativeclient и vcc.

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