Виталий Григорьев @VAAKAraceGUM
Ведущий системный архитектор
Информация
- В рейтинге
- Не участвует
- Откуда
- Москва, Москва и Московская обл., Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Software Architect, Pentester
Lead
Git
C++
Algorithms and data structures
Software development
Multiple thread
Code Optimization
Maths
Big data
Applied math
C++ STL
2. Я так понимаю, что плагины для Intellij Idea это тоже только коммерческая фишка? Вы о нем уже говорите в 3-й статье, а в общем репозитории его не найти. А как же CLion и Rider?
Для статического анализа подойдут такие простейшие проверки:
1. Внутри потока все исключения, которые могут произойти должны перехватываться.
2. Явный вызов join() или detach() после порождения потока далее по контексту (STL only).
3. Передача значения по ссылке std::cref() если оно не изменяется в потоке или далее по контексту выполнения.
4. Использование lock_guard() и unique_lock() c объектами синхронизации (не везде).
5. Использование scoped_lock() если надо заблокировать несколько объектов синхронизации.
И т.д.
Статический анализ свое место под солнцем может завоевать.
1. Если ДА, то хотелось бы видеть в Вашем продукте ряд проверок, направленных на анализ многопоточного кода. Абстрактно размышляя, количество объектов и методов синхронизации конечное множество, при этом, довольно, малое. Поиск параллельных участков кода и данных, с которыми имеют дело этот код — задача, достаточно, тривиальная. И при этом, количество диагностик, которые можно было бы написать в этой области достаточно большое (учитывая именно статический анализ кода, естественно, что покрывается не все и поэтому без valgrind и sanitaizer-ов не обойтись). Так же Ваш любимый CWE-362: Race Condition.
2. Так же хотелось бы видеть интеграцию со сборочными решениями уровня Enterprise (как единой точки входа для анализа) и иными IDE (в качестве полноценных плагинов) где это поддерживается, например, CLion/IntelliJ IDEA(в будущем), чтобы не править CMake файлы сборки.
Спасибо.