Тема продолжается и развивается. Теперь есть "60 антипаттернов для С++ программиста". Там не только больше "советов", но и есть пояснение по каждому из них.
Возможность такой записи ничего не решает. Ибо неизвестно, сколько бит нужно выбрать, чтобы оно совпало с размерностью size_t. Т.е. непонятно, сколько бит выбрать, чтобы счётчик мог перебрать все элементы любого массива. Как раз вектор развития, всячески избегать указания конкретной размерности.
Что что-то прибьёт 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 багов в открытых проектах. Но мы скромнее и не называем это УЯЗВИМОСТЯМИ!! ААА! Страшно, бойтесь! :)
Тема продолжается и развивается. Теперь есть "60 антипаттернов для С++ программиста". Там не только больше "советов", но и есть пояснение по каждому из них.
Возможность такой записи ничего не решает. Ибо неизвестно, сколько бит нужно выбрать, чтобы оно совпало с размерностью size_t. Т.е. непонятно, сколько бит выбрать, чтобы счётчик мог перебрать все элементы любого массива. Как раз вектор развития, всячески избегать указания конкретной размерности.
Дело было давно. К сожалению, ссылки постепенно умирают.
О нет, только не класс! Про это будет в "Вредный совет N56. Больше классов!".
Притензия непонятна. Там сказано, что погрешность может быть большой или малой. И даны отсылки. Предложите свой вариант правильного подхода. :)
Порядка нет, только путь фейспалма :)
Тема поиска ошибок с помощью ChatGPT однозначно интересная и мы уделим ей внимание. Однако, общую восторженность я не разделяю. Я просто оставлю это здесь: GPT-3 нашёл 213 Security Vulnerabilities… Или не нашёл.
Не аргумент. Бесплатные анализаторы кода не мешают продавать лицензии 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 компоненты.