Как стать автором
Обновить

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

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

Я бы тут отметил низкое качество кода PVS-Studio, поскольку это утверждение автоматически означает крайне высокую плотность ложных срабатываний.

У вас причинно-следственные связи нарушены. Из первого второе не следует никак.

Да ну? Если плотность предупреждений, указывающих на реальные недоработки, крайне низкая, то все остальные предупреждения — false positive и, соответственно, их плотность высокая. Их столь большое количество указывает не на высокое качество кода проекта, а на неумение эти срабатывания корректно отсеивать. Если на каком-то проекте мой гипотетический анализатор не осиливает находить множество реальных ошибок, но при этом находит много FP, то это не код проекта такой хороший, а мой анализатор такой плохой. Доля FP это прямой показатель качества анализатора, никак не анализируемого кода.

Про высокую долю FP при работе на Linux автор написал в начале статьи.

Но кто вам сказал, что автор делает вывод о высоком качестве кода, основываясь на соотношении true positive к false positive?!
В контексте предложения «плотность предупреждений, указывающих на реальные недоработки, крайне низкая» речь совсем не идет о ложных срабатываниях, их может быть вообще ноль (что никак не противоречит утверждению). Автор оценил качество кода Linux, и хотя этого недостаточно чтобы утверждать наверняка, но слабый Байесовский вывод о том что код Linux хорош можно сделать.
скрытый текст
Конечно «К сожалению, количество ложных срабатываний под Linux больше, чем хотелось бы.» Но это тоже слабый Байесовский довод к плохому качеству PVS-Studio, возможно FP там 1% и автор как сотрудник компании печалится о том что они вообще есть.

Хотя если оценивать трезво, то FP не менее 50%. И прошу прощения за занудство, но как иначе объяснить, осталось только разобрать высказывания на гипотезы, доводы и расставить формулы :)
Для читателей, пишущих на C++, могу порекомендовать std::string_view, который наконец-то появился в C++17. Лучше не передавать в функцию строки парой указатель-длина.


OMG С++, да ещё 17, да ещё в ядре???

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

Как избавиться от такой ошибки? В C можно использовать макрос наподобие:

#define str_len(S) (sizeof(S) / sizeof((S)[0]))



Естественно, никто не призывает использовать C++ в ядре.
НЛО прилетело и опубликовало эту надпись здесь
Если S не статический массив, то не важно null он или не null. Ничего хорошего всё равно не получится.
Поэтому:
Но использование таких макросов само по себе опасно: лучше конечно добавить compiler-specific проверок на то, что переданный аргумент действительно массив.
В ядре этих проверок есть. Кстати реакция Линуса на первую версию очень забавна.

Правильнее в данном случае использование обычного strcmp. Поскольку константы (const char *) все равно лежат в .rodata, то их повреждение это серьезная ошибка, которую неправильно маскировать применением strncmp.

А memcpy для строковых констант заменяем на strcpy.

Да. V743. The memory areas must not overlap. Use 'memmove' function.

Реальный пример из проекта Stickies:

#define EXPORTVERSION18  "StickyExport V1.8\032"

int LoadStickyData (void)
{
  char  chkBuff[32];
  int   versionLen = strlen (EXPORTVERSION18);
  ....
  memcpy (chkBuff, chkBuff+1, versionLen-1);
  ....
}

Немножко не в тему, но увидел очередную вашу статью и вспомнился один вопрос — скажите, а дружит ли ваш анализатор с такой вещью как dependency injection и насколько дружит?


Поясню откуда вопрос возник — столкнулся я тут с тем что в iOs если использовать Typhoon (наиболее популярная DI библиотеку), то clang-analyzer (он же пункт Analyze в Xcode) перестает видеть взаимодействие с классами которые добавляются при помощи DI (оно и понятно — нет явной связи в коде), вот и стало интересно как с этим у вас? Вроде бы в C# DI тоже весьма популярная штука, а у вас есть поддержка этого языка, про С/С++ если честно не в курсе в этом аспекте.

Прекрасная работа! В предыдущих постах вы писали о том, как после такой демонстрации отправляли результаты проверки разработчикам. А тут как это происходило, если произошло вообще?

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

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

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

Главное у другом — зубодробительные извращения, посвящённые творчеству стандартописателей разные платформы по разному обходят. Как-нибудь посмотрите на то, как какой-нибудь tgmath.h устроен (только чур — не просить потом «развидеть это»).
Немного оффтопа, но такое предложение. У вас же есть интеллектуальный анализ названий переменных и то что им присваивают или операций с ними?

Вот такой сегодня пример мне попался в коде, не долго отлавливал, но не спервого раза увидел в чем проблема:
if(year < 2017 && (month != 2016 || month < 7))

Суть предложения, если есть в названии переменной month, day — то проверять на адекватные границы значений в операциях с ними. Или вы уже это умеете?
Да, проверка эквивалентна:
if(year <= 2016 && month < 7)

Привел просто часть оригинального кода.
Стоп, не эквивалентна. Сам себя только что запутал.
Первый вариант корректный, только поменять month --> year.
Я бы такое условие написал как if (year < 2016 || (year == 2016 && month < 7))
И читается легче и работать будет быстрее.
Вот только не знаю, оно легче читается всеми, или это зависит от каких-то привычек.
Нет, такого анализа нет. Спасибо, обдумаем.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.