Отсутствие проверок (а компилятор не проверяет указатели и доступ по абсолютным адресам) провоцирует к опискам. А работа с указателями вдвойне опасна, т.к. указатель может принимать любое значение.
Еще опаснее работа с конфигурацией как с массивом, доступным по указателю. Одиночное чтение 1 параметра не по указателю безопасно, т.к. по сути является атомарной операцией.
Как пример проблем - пользователь использовал доступ по абсолютным адресам и превысил лимит ОЗУ на конфигурацию, заданный в таргете. Хотя у него была M версия, но размер области можно регулировать, а он этого не сделал, т.к. компилятор не предупредил его об этом (при доступе по абсолютным адресам проверок размера областей I/O не осуществляется). Как результат его мастер или slave стал работать с областью ОЗУ за пределами области конфигурации и портить данные в ней. Ошибка плавающая, т.к. поведение зависит от данных, записываемых в эту область. Наблюдались самопроизвольные остановки, зависания, порча данных, изменение алгоритма работы.
Другой пример - пользователь обращался к конфигурации как к массиву по указателю. И неверно учёл смещения данных. При этом он обращался к невыровненным данным как к выровненным, что вызывало исключительную ситуацию в процессоре и перезагрузку.
Ещё пример - опять указатели и обновление программы в режиме "online change" пользователь не отслеживал такой режим и ожидал что ПЛК сам поменяет значения указателей на таблицы констант (или вообще об этом не думал) - как результат указатели указывали не туда после смены ПО.
Т.о. работать так, конечно можно, но если делать надежное ПО с длительным циклом сопровождения - лучше не использовать указатели и использовать символьные имена переменных. Благо import/export конфигурации + текстовый редактор позволяют легко переносить и изменять конфигурацию не теряя настроек и символьных имён.
Ответить с цитированием