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

FDS>>Для осуществления контроля. Грубо говоря, я запускаю какую-нибудь функцию компилятора и смотрю распечатку всех модулей, где такие функции разрешены (ввода-вывода).
FDS>>Все остальные модули компилятор сам проверяет, что в них ничего такого нет.
·>В каком файле? В .exe? Тогда компилятор тут непричём. Ибо .exe после компиляции можно пропатчить, например.

Причём тут exe?

·>SecurityManager же гарантирует, что если код захочет обратиться к запрещённым операциям, то кинется исключение.

К сожалению, Java, в любом случае, не подходит.

Хотя я не очень понял, как там запрещать доступ к любым методам. Там файлы, сокеты есть. Ну я не особо разбирался.

Но это, всё равно, во время выполнения делается. А не во время компиляции.
Но, вообще говоря, интересно.
Забавно, что это в Java нашлось


FDS>>Это нужно, чтобы случайно не допустить ошибку и проще было бы контролировать операции ввода-вывода.
·>Такое решается управлением зависимостями. Т.е. "эти файлы завият от этих библиотек. Вот списочек библиотек". Тебе останется проверить, что среди этих библиотек нет таких, которые делают ввод-вывод.

Ну кто этот списочек-то составит?
Файлы не зависят от библиотек. Они зависят от других файлов.


FDS>>>> 2. Аналогичный запрет для всех функций, которые вызываются из данной функции
FDS>>·>Запрет на уровне класса.
FDS>>Как? Допустим, мне нужно точно сказать, что Class1 не осуществляет операций ввода-вывода.
FDS>>то есть мне нужно, чтобы компилятор это проконтролировал. Причём так, чтобы я сам не задумывался, куда этот Class1 обращается.
·>Это происходит в runtime. Условно говоря, если Class1 (и любой код им используемый) пытается обратиться к java.io.File, то кастомизированный ClassLoader просто кинет ClassNotFound.

Забавно.



FDS>>·>Это как? Если у некоего кода нет доступа к некоему состоянию, то и изменить не может, доступа к приватным данным тоже нет (кроме как через публичные методы). Или иммутабельные объекты что-ли?
FDS>>У меня есть массив данных. Я его передаю в функцию вычисления хеша. Я хочу, чтобы этот массив не был изменён этой функцией.
FDS>>Мало того, функция не должна изменять никаких объектов в программе, кроме создания и изменения новых.
·>Самый простой подход — защитная копия. Ты делаешь копию этого массива и передаёшь в функцию вычисления хеша. Даже если она что-то там поменяет, то пофиг, а к оригинальному массиву у неё просто не будет доступа, т.к. нет его адреса.

Тут смысл в том, что я не должен об этом думать. И тем более, копировать что-то в runtime.
1. Это загрязняет код
2. Это требует кодирования


·>Как вариант — делать read-only интерфейс доступа к тем же данным. Т.е. у тебя будет
·>public int getSize() и public byte getData(int index) — и всё. Функция может только получить размер и взять значение, а что-то поменять — тупо нечем.

Я понимаю, что так можно сделать. Но мне нужна простая программа. Я же не буду каждые данные копировать и интерфейсы на них писать.
Это слишком сложно.
Кроме этого, функция хеширования должна работать как можно быстрее. А тут на каждый доступ куча проверок.
Как раз хотелось бы в статике проверять.


FDS>>>> 4. Помечать объекты дополнительными типизационными метками (в статическом виде). Например, красная строка должна быть несовместима с зелёной строкой, но зелёная неявно приводима к красной.
FDS>>·>А чем просто типы не устраивают? class RedString {private final String content;}
FDS>>Представим себе, что я беру один символ красной строки и его помещаю в зелёную строку. Компилятор, в идеале, должен это отловить.
FDS>>То есть он должен все производные данные пометить также красной строкой.
·>Сделать RedSymbol...

Опять же, сделать вручную. Тогда проще сразу написать компилятор языка, который будет делать это автоматически.

FDS>>Плюс, нужно, чтобы можно было с гарантией видеть все приведения типов, чтобы их затем отдельно просматривать.
·>Не делать приведения типов. Делов-то.

Если я не буду делать приведений типов, то я никогда не смогу записать красную строку в зелёную.
А нужно смочь. И чтобы этих мест было как можно меньше.


FDS>>Плюс, у меня не должно быть сборщика мусора. Я как раз хочу уйти от него.
·>Это почему?

Во-первых, мне придётся самому его писать, если я буду делать загрузку через UEFI
Во-вторых, если он уже будет под Windows/Linux, то он не будет обнулять память.
А мне нужно гарантированно обнулять память. Чтобы в оперативной памяти после использования не оставалось никаких данных, которые уже не нужны.
Сборщик мусора это делает только случайно. Без гарантии. Что, если он что-то не перезапишет?