Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Прочее

Права доступа к переменным

Со времени предыдущих историй прошло всего-то лет пять, а как стал меняться компьютерный мир. В том числе, и в НПО. В отделах стали появляться персоналки: у кого IBM-PC/XT, у кого «Правец», у кого ЕС-1840. Число пользователей БЭСМ и даже ЕС и СМ-4 стало асимптотически приближаться к нулю. На фоне новых возможностей все их «фишки» сразу побледнели. Например, смешно, что еще недавно какая-нибудь замена терминала VT-340 на VT-52100 c памятью на 5 страниц, позволяющей вводить текст еще до включения БЭСМ, казалась важной.

            Расстаться со старыми заделами и навыками психологически мне было даже проще, чем многим, поскольку после двухлетнего отсутствия я вернулся на работу уже в другой отдел и, так сказать, сразу отрекся от старого мира и отряхнул его прах со своих ног. Впрочем, последние годы работа с БЭСМ через диалоговую программу «Пульт» (разработка МГУ) как раз очень напоминала работу за первыми персоналками и поэтому переход был несложным. А вот задачи стали другие. Отдел занимался разработкой ПО системы управления «Энергия-Буран». Точнее, отдел занимался комплексацией, верификацией, взаимодействием с наземным ПО и т.п., а собственно разработкой занималось сразу несколько отделов. Я впервые принимал участие в проекте, где были заняты десятки программистов. Язык программирования — ПРОЛ-2 разработки ИПМ АН СССР.

            Вообще-то, девичья фамилия этого языка была «Пролог-Ц» от ПРОграммирования ЛОГики. Но поскольку в то время на слуху был японский Пролог с его транспьютерами, вероятно разработчикам надоело отвечать на вопросы о применении транспьютеров в «Буране», поэтому вторая версия языка вышла под таким скромным и безликим именем.

            Язык был специфический, для задач управления. Типичный алгоритм выглядел так: выдать такую-то команду, подождать 0.3 миллисекунды, проверить такую-то переменную. Если она нулевая — выдать другую команду и запустить такой-то процесс. И все в таком духе.

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

            Сказано-сделано. Часть транслятора была написана на ассемблере и поэтому летал он ласточкой.

            В то время было модно извлекать из внутреннего динамика персоналки разные звуки. Ребята из моего бывшего отдела даже спаяли простой АЦП на параллельный разъем и через микрофон от древней «Яузы-5» мы записали ряд сигналов и фраз. Например, при отсутствии замечаний проверочный транслятор бесцветным голосом произносил половинку подходящего к случаю т.н. «заходеризма» (т.е. афоризма Б. Заходера): «если взглянуть формально, все обстоит нормально».

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

            Для повышения надежности в языке ПРОЛ-2 описание нелокальных переменных должно было включать и права доступа в виде списка имен процедур, которым разрешается к этой переменной обращаться.

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

            Но разбирательство показало, что таки-да, в штатном трансляторе помарка. Вероятно, она проникла в транслятор, когда выяснилось, что ресурсов одной БЦВМ не хватает и приняли решение поставить в «Буране» две машины, разделив ПО между ними. Транслятор подправили для двух ЭВМ, но он перестал проверять доступ переменной из процедуры на соседней БЦВМ (или, наоборот, на той же, я уже не помню). В общем, выключилась одна из проверок.

            После выяснения этого даже было совещание. Не столько на тему помарки в трансляторе, сколько на тему технологи разработки. Ведь рассчитывали на что? Что разработчики проанализируют сферу действия каждой переменной и явно и осмысленно укажут множество объектов, которые могут эту переменную читать/писать. А что получилось в реальности? Разработчики чихали на анализ и совали свои модули в транслятор. Ругнулся он по поводу прав — так и быть допишем список, не ругнулся — и так сойдет. В текстах даже нашли издевательские описания нелокальных переменных с пустыми списками, т.е. по правилам языка к ним вообще никто не мог обращаться. И при этом все работало нормально и казалось, что защита от порчи «чужих» данных хорошо обеспечена.

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

            А что, разве при отработке не было случаев, когда один процесс портил переменную другому процессу? Конечно, были. Только во всех этих случаях как раз с доступом все было хорошо.

            С тех пор прошло уже десятка три лет. Программирование и теоретически и практически ушло далеко вперед и добилось больших успехов.

            Но когда я читаю о новом языке, который «просто не позволит вам написать ошибочную конструкцию», о том, что какая-нибудь инкапсуляция или запрет преобразования типов автоматически сделают вашу программу надежной и правильной и о прочих, ежедневно отливаемых «серебряных пулях», я нет-нет, да и вспомню ту давнюю историю, как иллюстрацию того, что формальные методы борьбы за правильность и надежность чаще всего дают и формальные же результаты. В духе так и не озвученной нами в трансляторе второй половины афоризма Бориса Заходера.

Автор: Д.Ю.Караваев. 10.02.2017

Последняя правка: 2018-10-29    16:02

Оцените

Отзывы

     2018/10/21 13:50, Comdiv

Маловато материала для иронических выводов о формальных методах достижения корректности.

     2018/10/21 20:13, Автор сайта

Согласен: один частный случай не говорит о том, что формальные методы изрядно хромают. Но во фразе «в теории, теория и практика неразделимы; на практике это не так» больше правды, чем шутки. Читаю как-то на Хабре статью о том, как замечателен Haskell. Задаю в комментариях вопрос автору: «А как в этом языке отслеживается переполнение?». Мне отвечают: «Никак». Язык, который вроде бы как находится на передовом рубеже, — и никак. Между тем Дмитрий Юрьевич в своём компиляторе PL/1 контролизует переполнения и бьёт тревогу из-за того, что команда INTO, которая делала такой контроль «дешёвым», исключена из архитектуры x86-64. Т.е. на словах он критикует, а на деле делает то, что и должно.

Здоровый скепсис по поводу чьих-то разрекламированных возможностей полезен.

     2018/10/22 15:13, Comdiv

Переполнение чего — массивов? Судя по REPL контролируется. Если чисел, то числа там безразмерные. Это далеко не всегда хорошо, даже если не учитывать производительность.
А скепсис — он для всего полезен. Но за скепсис у нас нередко принимают нечто иное.

С формальными методами есть следующие проблемы психологического характера, связанными и с непониманием теории:

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

2. Очень сложно оценить предотвращение чего-либо. Когда формальный метод спасает от ошибки, то Вы просто этого не замечаете. В силу 1-го пункта ошибка всё равно может проявится, а уж это Вы заметите. После этого можно смело иронизировать про формальные методы, особенно, если они не смогли предотвратить ошибку, не связанную с ними.

3. Люди любят всё доводить до абсурда, чтобы ни было предложено.

Написать отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Каким должен быть язык программирования?

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Двадцать тысяч строк кода, которые потрясут мир?

Почему владение/заимствование в Rust такое сложное?

Масштабируемые архитектуры программ

Почему Хаскелл так мало используется в отрасли?

Бесплатный софт в мышеловке

Исповедь правового нигилиста

Русской операционной системой должна стать ReactOS

Почему обречён язык Форт

Программирование без программистов — это медицина без врачей

Электроника без электронщиков

Статьи Дмитрия Караваева

●  Идеальный транслятор

●  К вопросу о совершенствовании языка программирования

●  О реализации метода оптимизации при компиляции

●  О реализации метода распределения регистров при компиляции

●  О распределении памяти при выполнении теста Кнута

●  Опыты со стеком или «чемпионат по выполнению теста Кнута»

●  О размещении переменных в стеке

●  Сколько проходов должно быть у транслятора?

●  Чтение лексем

●  Экстракоды при синтезе программ

●  Об исключенных командах или за что «списали» инструкцию INTO?

●  Типы в инженерных задачах

●  Непрерывное компилирование

●  Об одной реализации специализированных операторов ввода-вывода

●  Особенности реализации структурной обработки исключений в Win64

●  О русском языке в программировании

●  Формула расчета точности для умножения

●  Права доступа к переменным

●  Скорость в попугаях

●  Крах операции «Инкогнито»

●  Предопределенный результат

Компьютерный юмор

Прочее

Последние комментарии

2018/12/08 23:03 ••• Попов Михаил
✎ Программирование без программистов — это медицина без врачей

2018/12/07 08:57 ••• Автор сайта
✎ Почему обречён язык Форт

2018/12/07 08:36 ••• Автор сайта
✎ Нужны ли беззнаковые целые?

2018/12/03 13:51 ••• kt
✎ Экстракоды при синтезе программ

2018/11/30 17:56 ••• Freeman
✎ Изменение приоритетов операций

2018/11/30 17:20 ••• Автор сайта
✎ Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

2018/11/26 14:23 ••• Автор сайта
✎ Так ли нужны операции «&&», «||» и «^^»?

2018/11/18 15:21 ••• Freeman
✎ Устарел ли текст как форма представления программы

2018/11/17 03:28 ••• Comdiv
✎ Изменение длины объекта в стеке во время исполнения

2018/11/16 12:53 ••• Автор сайта
✎ Помеченные комментарии

2018/11/11 14:01 ••• Александр Коновалов aka Маздайщик
✎ Нерабочий код

2018/11/11 13:39 ••• Александр Коновалов aka Маздайщик
✎ О русском языке в программировании