Что что-то прибьёт PVS-Studio я уже читаю более десяти лет :). То Cppcheck, то Clang... То свежий Visual Studio 2010 (пример: "Народ против PVS-Studio: дубль первый"). Не страшно. Однако, считаю полезным знакомить читателей в комментариях (пример) или в таких вот статьях, с реальностью.
Я не разделяю энтузиазм и восторг автора статьи. Наши собственные недавние эксперименты с ChatGPT показали куда более скромные и неоднозначные результаты. Публикация на эту тему: Хорошо ли ChatGPT ищет ошибки в коде?
Мне кажется, ChatGPT очаровал автора и он приписывает ему правильные ответы, даже там где их нет. Этим, возможно, и объясняется только одно замеченное ложное срабатывание. Если не хотеть их замечать, то их и не будет :)
Почему я столь скептичен? Автор скорее всего приводит самые красивые и сильные примеры работы ChatGPT. Согласитесь, вряд ли он отбирал слабые примеры :). Так вот, даже в этих отобранных примерах удачной работы имеются незамеченные автором ложные срабатывания.
Возьмём первый пример.
int main(int argc, char **argv) {
printf(argv[1]);
В целом я согласен с вторым пунктом: Format string vulnerability. Хотя и тут можно придраться к формулировке. Собственно проверять необязательно, нужно просто по-другому использовать printf. Объяснение ошибки явно проигрывает документации классических статических анализаторов: V618. Ну да ладно, первое сообщение более мне интересно.
"Unvalidated user input: The program does not check the length of the user input, which could lead to a buffer overflow attack.". На мой взгляд это ложное срабатывание. Нет проверки количества аргументов (переменной argc). Здесь ошибка: возможен выход за границы массива argv. А GPT-3 начинает философствовать про какие-то переполнения буфера. Можно, конечно, сказать, что это одно и то же... Но это тогда можно просто сказать "у вас тут ошибка". Если это так - повезло. А если нет, то извините :). Когда программисты говорят про переполнение буфера? Когда имеется в виду именно работа с нуль-терминированной строкой, неправильное использование strcat, memcpy и т.п.
Ладно, возможно, это было неубедительное ложное срабатывание. Хорошо, вот код из 3-его примера:
fp = fopen(filename,"r");
if(fp == NULL)
{
printf("\nCan't open file or file doesn't exist.");
exit(0);
}
Не понимаю, как можно сказать, что это правильное предупреждение: Unchecked return value: The return value of the fopen() function is not checked, which could lead to a null pointer dereference. GPT-3 явно облажался, а автор не захотел это заметить.
Uninitialized memory access: The OOBR_stack and OOBR_heap variables are accessed without being initialized, which could lead to undefined behavior.
Полная фигня. Вот же инициализация. Эти переменные никак нельзя назвать неинициализированными. Другое дело, что при их инициализации происходит выход за границы массива, но это совсем другая ошибка, про которую GPT-3 ничего не сказал. Ещё GPT-3 неправ, говоря про доступ к неинициализированным переменным OOBR_stack и OOBR_heap. Они вообще нигде не используются.
В общем, это предупреждение на первый взгляд выглядит умным и полезным, но по своей сути совершенно мимо. Скорее всего, также дело обстоит и с другими ошибками, которые в статье не приведены.
P.S. Слишком пафосно называть всё это уязвимостями. Это просто ошибки. Возможно, некоторые из них являются потенциальными уязвимостями, но не более того. Вот когда найденный дефект можно использовать в своих целях, то тогда да - это уязвимость. Иначе это просто баг, которых тысячи в любых приложениях :). Я то точно знаю, что таких багов полно везде. С помощью PVS-Studio мы уже обнаружили более 15000 багов в открытых проектах. Но мы скромнее и не называем это УЯЗВИМОСТЯМИ!! ААА! Страшно, бойтесь! :)
А мне практика говорит, что статический анализ крайне полезен в плане нахождения ошибок на ранних этапах. Я уже несколько раз делал заметки про то, что регулярно посматриваю на новые ошибки в проекте Blender. Последняя из них: "0, 1, 2, Фредди забрал Blender". Я вижу, как почти каждый день PVS-Studio находит новую ошибку в свежем коде Blender или по крайней мере код с запахом. Естественно, каждый день писать про это я не буду. Это будет скучно и мне и читателям. Однако, проект бы выиграл, если начать использовать PVS-Studio на регулярной основе.
Программист поспешил и в процессе рефакторинга опечатался. Скорее всего эта ошибка потом будет замечена. Но лучше, если она будет обнаружена статическим анализатором, а не при тестировании или вообще пользователем.
Мы всегда уведомляем разработчиков о найденных ошибках. Почему мы сами не делаем Pull Requests для исправления найденных ошибок? Если кратко, то есть 3 причины:
Мы постоянно что-то проверяем. Количество найденных ошибок в открытых проектах давно перевалило за 15000. Если мы будем все их пытаться править, то это надо на постоянную основу брать пару человек, которые только и будут этим заниматься. Пока мы не можем позволить себе такое баловство.
Мы не знакомы с проектом и часто просто не знаем, как править ошибки. Т.е. то что это ошибка, это понятно, а как править — нет.
При написании статей у нас не полноценный, а поверхностный анализ, цель которого популяризация статического анализа кода. Да, какие-то ошибки будут поправлены, но вовсе не все, которые можно обнаружить. Если уж править, то надо подойти к этому серьезно. Это лучше и качественнее сделают разработчики проекта, а не мы. Более того, статический анализ надо использовать регулярно, а не от случая к случаю. Подробнее эта мысль изложена здесь: "Ошибки, которые не находит статический анализ кода, потому что он не используется".
Не аргумент. Бесплатные анализаторы кода не мешают продавать лицензии PVS-Studio.
Что что-то прибьёт PVS-Studio я уже читаю более десяти лет :). То Cppcheck, то Clang... То свежий Visual Studio 2010 (пример: "Народ против PVS-Studio: дубль первый"). Не страшно. Однако, считаю полезным знакомить читателей в комментариях (пример) или в таких вот статьях, с реальностью.
Примечание на всякий случай. PVS-Studio работает как standalone-приложение и не нуждается в подключение к сети.
Более развёрнутый вариант этого комментария: GPT-3 нашёл 213 Security Vulnerabilities… Или не нашёл.
Продолжаем тему полезного и интересного: Reddit для программистов.
Не понял мысль и как это связано с моим комментарием. Прошу пояснить.
Если замечать такие ляпы, то не получится написать восторженную статью :) Ну или автор на самом деле слабый программист и не понимает, что пишет.
У нас недавно заметка была: Хорошо ли ChatGPT ищет ошибки в коде? А по поводу этой статьи, написал ниже.
Я не разделяю энтузиазм и восторг автора статьи. Наши собственные недавние эксперименты с ChatGPT показали куда более скромные и неоднозначные результаты. Публикация на эту тему: Хорошо ли ChatGPT ищет ошибки в коде?
Мне кажется, ChatGPT очаровал автора и он приписывает ему правильные ответы, даже там где их нет. Этим, возможно, и объясняется только одно замеченное ложное срабатывание. Если не хотеть их замечать, то их и не будет :)
Почему я столь скептичен? Автор скорее всего приводит самые красивые и сильные примеры работы ChatGPT. Согласитесь, вряд ли он отбирал слабые примеры :). Так вот, даже в этих отобранных примерах удачной работы имеются незамеченные автором ложные срабатывания.
Возьмём первый пример.
В целом я согласен с вторым пунктом: Format string vulnerability. Хотя и тут можно придраться к формулировке. Собственно проверять необязательно, нужно просто по-другому использовать printf. Объяснение ошибки явно проигрывает документации классических статических анализаторов: V618. Ну да ладно, первое сообщение более мне интересно.
"Unvalidated user input: The program does not check the length of the user input, which could lead to a buffer overflow attack.". На мой взгляд это ложное срабатывание. Нет проверки количества аргументов (переменной argc). Здесь ошибка: возможен выход за границы массива argv. А GPT-3 начинает философствовать про какие-то переполнения буфера. Можно, конечно, сказать, что это одно и то же... Но это тогда можно просто сказать "у вас тут ошибка". Если это так - повезло. А если нет, то извините :). Когда программисты говорят про переполнение буфера? Когда имеется в виду именно работа с нуль-терминированной строкой, неправильное использование strcat, memcpy и т.п.
Ладно, возможно, это было неубедительное ложное срабатывание. Хорошо, вот код из 3-его примера:
Не понимаю, как можно сказать, что это правильное предупреждение: Unchecked return value: The return value of the fopen() function is not checked, which could lead to a null pointer dereference. GPT-3 явно облажался, а автор не захотел это заметить.
В этом-же третьем примере:
Uninitialized memory access: The OOBR_stack and OOBR_heap variables are accessed without being initialized, which could lead to undefined behavior.
Полная фигня. Вот же инициализация. Эти переменные никак нельзя назвать неинициализированными. Другое дело, что при их инициализации происходит выход за границы массива, но это совсем другая ошибка, про которую GPT-3 ничего не сказал. Ещё GPT-3 неправ, говоря про доступ к неинициализированным переменным OOBR_stack и OOBR_heap. Они вообще нигде не используются.
В общем, это предупреждение на первый взгляд выглядит умным и полезным, но по своей сути совершенно мимо. Скорее всего, также дело обстоит и с другими ошибками, которые в статье не приведены.
P.S. Слишком пафосно называть всё это уязвимостями. Это просто ошибки. Возможно, некоторые из них являются потенциальными уязвимостями, но не более того. Вот когда найденный дефект можно использовать в своих целях, то тогда да - это уязвимость. Иначе это просто баг, которых тысячи в любых приложениях :). Я то точно знаю, что таких багов полно везде. С помощью PVS-Studio мы уже обнаружили более 15000 багов в открытых проектах. Но мы скромнее и не называем это УЯЗВИМОСТЯМИ!! ААА! Страшно, бойтесь! :)
В продолжении темы статья от нашей команды: Хорошо ли ChatGPT ищет ошибки в коде? (C#).
Пришло время посмотреть на ChatGPT: Хорошо ли ChatGPT ищет ошибки в коде? (C#).
Время PVS-Studio: Приключения капитана Блада: потонет ли Арабелла? :)
Если нужен, то теперь его ещё и проверять можно с помощью PVS-Studio :)
PVS-Studio научился анализировать Blazor компоненты.
А вот и новое за 2022 год! Топ-10 ошибок в C++ проектах за 2022 год.
А мне практика говорит, что статический анализ крайне полезен в плане нахождения ошибок на ранних этапах. Я уже несколько раз делал заметки про то, что регулярно посматриваю на новые ошибки в проекте Blender. Последняя из них: "0, 1, 2, Фредди забрал Blender". Я вижу, как почти каждый день PVS-Studio находит новую ошибку в свежем коде Blender или по крайней мере код с запахом. Естественно, каждый день писать про это я не буду. Это будет скучно и мне и читателям. Однако, проект бы выиграл, если начать использовать PVS-Studio на регулярной основе.
Вот из сегодняшнего:
Программист поспешил и в процессе рефакторинга опечатался. Скорее всего эта ошибка потом будет замечена. Но лучше, если она будет обнаружена статическим анализатором, а не при тестировании или вообще пользователем.
Мифы о статическом анализе. Миф второй – профессиональные разработчики не допускают глупых ошибок (p.s. пожалуй надо будет переписать на новый лад, а то материал выглядит устаревшим, хотя на самом деле с 2011 года ничего не изменилось :)
Возможно. Ничего, разберутся :)
Проверка PVS-Studio с помощью Clang (правда это 2014 год, а потом мы это регулярно делаем).
Мы всегда уведомляем разработчиков о найденных ошибках. Почему мы сами не делаем Pull Requests для исправления найденных ошибок? Если кратко, то есть 3 причины:
Мы постоянно что-то проверяем. Количество найденных ошибок в открытых проектах давно перевалило за 15000. Если мы будем все их пытаться править, то это надо на постоянную основу брать пару человек, которые только и будут этим заниматься. Пока мы не можем позволить себе такое баловство.
Мы не знакомы с проектом и часто просто не знаем, как править ошибки. Т.е. то что это ошибка, это понятно, а как править — нет.
При написании статей у нас не полноценный, а поверхностный анализ, цель которого популяризация статического анализа кода. Да, какие-то ошибки будут поправлены, но вовсе не все, которые можно обнаружить. Если уж править, то надо подойти к этому серьезно. Это лучше и качественнее сделают разработчики проекта, а не мы. Более того, статический анализ надо использовать регулярно, а не от случая к случаю. Подробнее эта мысль изложена здесь: "Ошибки, которые не находит статический анализ кода, потому что он не используется".
Теоретически. Практически: Использование машинного обучения в статическом анализе исходного кода программ.