Ограничение прав доступа к переменным

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

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

    Впрочем, последние годы работа с БЭСМ-6 через диалоговую программу «Пульт» разработки МГУ, как раз очень напоминала работу за первыми персоналками и поэтому переход был несложным.

    А вот задачи стали другие. Отдел занимался разработкой ПО системы управления «Энергия-Буран». Точнее, отдел занимался комплексацией, верификацией, взаимодействием с наземным ПО и т.п., а собственно разработкой занималось сразу несколько отделов. Я впервые принимал участие в проекте, где были заняты десятки программистов. Язык программирования – ПРОЛ-2 разработки ИПМ АН СССР.

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

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

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

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

    В то время было модно извлекать из внутреннего динамика персоналки разные звуки. Ребята из моего бывшего отдела даже спаяли простой АЦП на параллельный разъем и через микрофон от древней «Яузы-5» мы записали ряд сигналов и фраз.

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

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

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

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

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

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

    А что получилось в реальности? Разработчики чихали на анализ и совали свои модули в транслятор. Ругнулся он по поводу прав – так и быть допишем список, не ругнулся – и так сойдет. И при этом все работало нормально и казалось, что защита от порчи «чужих» данных хорошо обеспечена.

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

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

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

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

    В духе так и не озвученной нами в трансляторе второй половины афоризма Бориса Заходера.

    Комментарии 9

      0
      Вторая часть цитаты Б. Заходера тоже заслуживает увековечивания на Хабре, добавьте пожалуйста.
        +1
        Вроде эта вторая часть подходит:
        "… Злые люди
        Бедной Киске
        Не дают
        Украсть
        Сосиски!"
        — это про ограничение прав доступа
          0
          <Оффтоп!> А вот интересно, Борис Заходер знал альтернативное значение слова «Киска»? ;-)
          Это несколько меняет смысл стихотворения…
          «Он мечтал издать свои книги для взрослых, но в печать допускали только его детские произведения и переводы зарубежных книг.»
          </Оффтоп>
          АЦП на LPT на резисторах, это да… COVOX. Помнится в конце девяностых сделах себе такую штуку на IBM PC 286. Я написал на Си драйвер, который на одном LPT порту, под DOS, позволял одновременно печатать на принтере и слушать музыку.
          И потом, на его базе, сделал свой синтезатор речи на фонемах. Вполне разборчиво говорил.
          0
          вторая часть идёт после запятой «всё обстоит нормально».
          0

          Давно была подобная идея для c# сделать, на атрибутах и синтаксическом анализаторе довольно просто реализовать.


          Проблема в том что есть ощущение что как в примере из статьи и с checked exceptions в java, будет использоваться формально и принесёт больше неудобств чем пользы.

            0
            Это же зависит от программистов. Кто-то будет использовать формально или вообще не использовать, а кому-то такая фича и поможет.
            0
            формальные методы борьбы за правильность и надежность чаще всего дают и формальные же результаты

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

              0
              На всякий случай вот исходная статья с содержательными комментариями.
                +1
                Опять пришли ситхи и всё возвели в абсолют. Пока одни пытаются создать механизмы уменьшающие количество ошибок — другие воротят нос, мол смотрите, у вас в коде проверки на ошибки тоже ошибки бывают.
                У меня один вопрос: А чего вы на ассемблере не пишете? Или сразу в машинных кодах? Кодогенераторы в компиляторах ведь тоже код и в них тоже бывают ошибки…

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое