Comments 26
UFO landed and left these words here

Компиляторы со временем сделают ненужными специализированные статические анализаторы, или будут вечно догонять?

DFA анализ компилятора гораздо круче, чем набор эвристик в линтере. Либо же линтер станет сложнее в разработке (и дороже) компилятора.
Не хочу спорить, но можно просто прогнать примеры из статьи через их линтер (особенно интересно с setjump или signal).

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

Любопытно, сколько ошибок тогда обнаружится?

Достаточно мощный clang static-analyzer давно есть, однако ж...


Да и простые ворнинги компилятора включают не везде.

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

Не пострадает по двум причинам.
  1. Кролики — это не только ценный мех, но и три — четыре килограмма диетического, легкоусвояемого мяса. PVS-Studio – это не только поиск ошибок в коде, но и развитая инфраструктура. Например, это интеграция с такими системами, как SonarQube, PlatformIO, Azure DevOps, Travis CI, CircleCI, GitLab CI/CD, Jenkins, Visual Studio. Это развитые механизмы массового подавления предупреждений, что позволяет быстро начать использовать PVS-Studio даже в большом старом проекте. Это рассылка уведомлений. Это поддержка клиентов. И так далее, и так далее.
  2. PVS-Studio тоже не стоит на месте. Собственно, у нас многие компиляторы и заимствуют. Тот же GCC. Пруфов не будет, но это было. Просто как-то нет смысла ловить кого-то за руку. Ну, если только случайно. Почему нет смысла ловить, так это потому, что улучшение диагностических возможностей идёт всем на пользу. Мир программ становится лучше. А нас это держит в тонусе и заставляет активно наращивать мощности.
Прекрасно что Вы здесь! Отлавливает ли PVS-Studio ошибки в примерах в этой статье?

Повторюсь, особенно интересно с примерами setjump или signal.

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

Компиляторы со временем сделают ненужными специализированные статические
анализаторы, или будут вечно догонять?

ИМХО бессмысленно их противопоставлять. В самом начале статьи указано
ключевое отличие:


Я стремился к тому, чтобы -fanalyzer «всего лишь» удвоил время компиляции в качестве
разумного компромисса между дополнительными проверками. У меня пока не получилось

Даже если и получится, то при добавлении новых проверок (список сейчас какой-то очень маленький по сравнению с clang static-analyzer) время снова существенно возрастет,
вот это и отличие статического анализатора и компилятора и от этого никуда не уйдешь.


Больше статически проверок -> неудобно запускать во время компиляции -> используется
как отдельный компонент / статический анализатор


Большинство статических анализаторов созданы на основе существующих компиляторов, тот же PVS и все они отдельные инструменты, а не часть компиляторов.


Ну, как сказать… Код из GCC 10:
tree
vn_reference_lookup_pieces (....)
{
  struct vn_reference_s vr1;
  ....
  vr1.set = set;
  vr1.set = base_set;
  ....
}

Предупреждение PVS-Studio: V519 The 'vr1.set' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 3448, 3449. tree-ssa-sccvn.c 3449
:)

Интересно, есть какая-то возможность пометить собственные функции как malloc и free? Зачастую во встраиваемых проектах, где сейчас часто и применяется C приходится писать свой, либо использовать альтернативный аллокатор/деаллокатор. То же самое касается fopen и т.д… Что если я не использую стандартную библиотеку?
Насчёт GCC не знаю, но в анализатор PVS-Studio можно (см. раздел «Как задать псевдоним для системной функции»). И кстати, на подходе статья по проверку GCC 10 :).
А существовали ли ошибки в GCC 10, которые были обнаружены/исправлены в ходе компилации его исходного кода с помощью GCC 10 с -fanalyzer? И было бы интересно сравнить долю ложных срабатываний на исходном коде GCC 10 у PVS-Studio и самого GCC 10.
К сожалению, не получится ничего сравнить. Анализатор GCC разрабатывается с учетом кода GCC и настроен под его особенности. И наоборот, стиль написания кода GCC подстроен под анализатор GCC. Это естественно, уменьшать шум чтобы иметь возможность пользоваться.

PVS-Studio при первом запуске (без настроек) проиграет. Собственно, так и есть. В статье, которая скоро будет, я пишу, что PVS-Studio сходит с ума от всех этих макросов. Это не проблема. Но нужна настройка. Просто я хотел пояснить, что сравнить, это намного сложнее чем может казаться. Сравнение требует настройки и плюс тут возникает вопрос, где в этой настройки для честности остановиться. В общем, задача нерешаема :).

Лучшая реклама PVS-Studio. Даже если GCC-овый находит больше, работа с его выводом убивает.

Спасибо за перевод и внимание к теме статьи!

Хочу сказать про PVS-Studio. Когда в компиляторе от Microsoft появился статический анализ С++, все говорили что теперь PVS-Studio умрет. Затем появился статический анализ в clang. И стало понятно, что теперь-то точно умрет PVS-Studio. Потом появился Roslyn. Сомнений в смерти PVS-Studo для C# не оставалось ни у кого, ведь теперь любой может делать свои анализаторы! Бесплатно! Да и при живом-то Resharper. PVS-Studio для Java при наличии IntelliJ идея тоже не самая очевидная. Теперь вот в GCC появился статический анализ…

Крах PVS-Studio очевиден уже почти всем. Только две категории людей об этом не знают. Разработчики PVS-Studio и их клиенты. Скажите уже им кто-нибудь!

P.S. Мы приветсвуем появление статического анализа в GCC. Чем больше разработчиков узнает об этой технологии, тем больше у нас работы.
Про «умрет» и конкретно про PVS-Studio в статье ни слова. Ваш комментарий немного мимо.

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

Когда-нибудь PVS-Studio таки помрет. Вопрос только в том, когда и как.
Понятно, что это произойдет не в ближайшем будущем, хотя бы потому, что компиляторам еще догонять и догонять.
И не факт, что его похоронит именно какой-нибудь компилятор, в который будет включен полновесный статический анализатор.
Вполне возможно, это будет что-то вроде ИИ, который будет следить за кодом в реальном масштабе времени и пинать программиста (удар током через клавиатуру :) ) за ляпы, ошибки и подозрительные конструкции (весьма далекое будущее).
Другой вариант, что его убьет то, что программистов почти полностью заменит что-то автоматическое, которое будет программировать сразу в машинных кодах и будет само себе анализатором возможных проблем.

Очень слабая статья, не имеющая отношения к статическому анализу. Кликбейт?
Only those users with full accounts are able to leave comments. Log in, please.