Комментарии 26
Проблема проста — не используют возвращаемое логическое значение метода empty, указывающее, пуст ли контейнер. Судя по тому, что в приведённом выражении кроме вызова метода ничего нет, можно предположить, что разработчик хотел очистить контейнер, но ошибся, вызвав метод empty вместо clear.
Проблемы не возникло бы, если бы метод назывался is_empty.
При этом все ошибки фиксятся на кодревью
Ха-ха. :) 13645 ошибок найденных нами в открытых проектах.
Мы много общаемся с руководителями разработок разных компаний на тему контроля качества кода. Так вот, в общем случае, кодревью служит только для проверки логики работы внесённых изменений в код, немножко code style и практически ничего (из серии «случайно бросилось в глаза») по ляпам разного характера.
Вообще предупреждение на первое место хорошо бы изменить: у разработчика возникнет ощущение, что ваш анализатор просто ошибся. Без вашего детального разъяснения понять где ошибка реально тяжело.
Эх, чем больше смотрю на эти перечни "тупых" или "непреднамеренных" ошибок типа копипаста и т.п., тем больше задаюсь вопросом, сколько же тогда ошибок кроется в рантайме (когда код по задумке разработчика написан верно, так, как он и хотел, но сама логика программы при этом не верна)
Если программа работает, это не значит, что в ней нет ошибок.
Если в программе нет ошибок, это не значит, что она работает правильно.
И хотя я понимаю, что авторы этой статьи не смогут реализовать это, но помечтать вслух не запрещено ведь?
Круто было бы, если бы возле каждой проверки был описан результат-баг в реальном продукте. К примеру, вызвал empty вместо clear — массив не очистился, потом метод Х использовал этот массив, вернул неправильные данные методу В и тот сохранил пустой файл вместо файла с данными.
Круто было бы, если бы возле каждой проверки был описан результат-баг в реальном продукте. К примеру, вызвал empty вместо clear — массив не очистился, потом метод Х использовал этот массив, вернул неправильные данные методу В и тот сохранил пустой файл вместо файла с данными.
Это делать можно, но это очень трудоёмко. По крайней мере регулярно писать подобные статьи мы не осилим.
Какой только фигни в коде не напишешь когда руководитель департамента теребит каждые полчаса «где релиз, когда релиз» а программистов по пальцам одной руки пересчитать можно
Каждый раз, как читаю о PVS возникает желание вернуться на C++. Автоматический поиск багов вызывает чувство уюта.: )
Нет ли в планах JS? Неиспользуемые параметры метода или ошибки в логических условиях выглядят реализуемо для динамического языка.
Нет ли в планах JS? Неиспользуемые параметры метода или ошибки в логических условиях выглядят реализуемо для динамического языка.
(del)
В Chromium недавно всплыл интересный баг, который, похоже, вполне мог быть отловлен статическим анализом:
https://bugs.chromium.org/p/chromium/issues/detail?id=835506
Краткое описание на русском
Отлавливали ли вы этот баг в прошлых проверках Chromium?
https://bugs.chromium.org/p/chromium/issues/detail?id=835506
Краткое описание на русском
Отлавливали ли вы этот баг в прошлых проверках Chromium?
По всей видимости нет. Но у нас при написании статей и нет задачи найти как можно больше багов в проекте. :)
Вопрос был еще и в том, может ли PVS-Studio находить подобную ошибку?
Суть бага:
void buggy_function()
{
float* table = nullptr;
if (some_condition) {
float another_table[] = { 0.1, 0.2, 0,3 };
table = another_table;
}
some_other_function(table);
}
Память выделенная на стеке продолжает использоваться за пределами блока через указатель, что раньше прокатывало, но при переходе на новую версию компилятора привело к трудноуловимому багу.
Суть бага:
void buggy_function()
{
float* table = nullptr;
if (some_condition) {
float another_table[] = { 0.1, 0.2, 0,3 };
table = another_table;
}
some_other_function(table);
}
Память выделенная на стеке продолжает использоваться за пределами блока через указатель, что раньше прокатывало, но при переходе на новую версию компилятора привело к трудноуловимому багу.
Нет, пока такую ошибку анализтор не найдёт.
зато такую ошибку прекрасно найдет сам Clang/gcc, точнее AddressSanitizer github.com/google/sanitizers/wiki/AddressSanitizerExampleUseAfterScope
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статический анализ в видеоигровой индустрии: топ-10 программных ошибок