Безопасные функции

12 Февраля 2008 Программирование
2 0

Не секрет, что достаточно большая часть ответственности за безопасность кода лежит на функциях, особенно это относится к С/С++, где повсеместно используются строки, заканчиваются нулем. Это не только самый большой тормоз, но и самый дырявый тип данных. Второй источник проблем безопасности - нарушение логики или ошибки проектирования. Что страшнее? Я не берусь ответить на этот вопрос однозначно, хотя мне кажется, что вторая проблема опасноснее, потому что ее сложнее вычеслить.

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

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

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

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

И вот тут у меня возник вопрос: "Зачем производители компиляторов плодятся функции, которые небезопасны? Зачем MS оставляет старые функции в библиотеке, а выдумывает новые?". Лично я ответа на вопрос не вижу, ведь компания сама дает нам инструменты, которые содержат потенциально опасные возможности.

Простой пример - функция генерации случайных чисел? Кто не знает, что библиотечная функция не генерирует случайных чисел и каждое последующее число можно предугадать? Shame on you! При этом, производители не исправляют функцию, что является потенциальной опасностью, особенно в системах шифрования, а в это время функции генерации случайности плодятся.

Почему не исправисть стандартную функцию? И не нужно говорить, что она стандартная и ее трогать нельзя! Каждый компилятор С++ реализует ее по своему. Сравните код реализации rand в компиляторах GCC, Borland C++, VC++ или любом другом, и вы увидите, что они разные. Получается, что функцию изменять можно!

Единственный спорный вопрос - производительность. Стандартные функции оптимизированы на скорость, чтобы выдать результат уже через мгновение, поэтому компиляторы хвастаются скоростью создаваемого кода. Но что важнее - безопасность или скорость? Для меня ответ однозначен - безопасность.

Слышу вопрос из третьего ряда: "А как же игры, ведь в них нужна скорость?". В них тоже необходимы реально случайные числа. Искусственный интеллект обязательно использует случайные числа, и если они будут предсказуемым, то монстры будут тупыми, как валенки. Ты играл в такие игры? Я да, и абсолютно не интересно мочить тупиков даже в сортире. На самом деле генератор случайных чисел тормозит только во время инициализии, а потом выдает числа очень быстро, так что игры потеряют всего несколько тактов на этапе загрузки.

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

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

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

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым