Нам в поддержку написал пользователь о странном ложном срабатывании анализатора PVS-Studio. Сейчас станет понятно, почему этот случай заслуживает отдельной маленькой статьи и насколько у программистов может быть замылен взгляд.
Время от времени мы пишем статьи в духе "статический анализатор внимательнее C++ программиста". Сегодня мы продолжим эту традицию, разве что заменив "программист" на "хакер".
Сегодня мы посмотрим, как маленькие оптимизации в нужных местах приложения могут неплохо повысить его производительность. Убрали создание лишнего итератора в одном месте, избавились от упаковки в другом, а в итоге получается результат, несоизмеримый с правками.
Если быть честными, говоря о работе, то давайте признаемся: даже самое любимое дело может время от времени наскучивать, сводить на нет настроение и изматывать однообразностью. Поэтому в нашем офисе PVS-Studio мы стараемся раскрасить яркими красками наши будни. Сегодня будет рассказ об одном из таких нововведений — геймификации достижений нашего коллектива.
Из этой статьи вы узнаете, как запустить проверку embedded-проекта и как работать с отчетом анализатора. Анализатор PVS-Studio поддерживает ряд компиляторов для встраиваемых систем. В текущей версии возможна проверка проектов при сборке одним из следующих компиляторов под Window, Linux и macOS:
byte* regionStart;
size_t regionSize;if (p >= regionStart && p < regionStart + regionSize)
Мне предложили проверить библиотеки, входящие в Visual Studio 2013. Ничего особенно примечательного я не нашёл. Только несколько мелких ошибок и недочётов. Интригующую статью из этого не сделаешь, но я всё равно опишу замеченные недостатки. Надеюсь, это сделает библиотеки чуть лучше, и подвигнет авторов провести более тщательную проверку. У меня нет файлов проектов для сборки библиотек. Поэтому я проверял файлы кое-как, и много могло быть пропущено.
Статический анализ — это очень мощный инструмент, позволяющий следить за качеством кода. Предлагаем вместе попробовать написать простой Lua анализатор на Java, чтобы понять, как устроены статические анализаторы кода внутри.
Я согласен, что ошибка выделения памяти с помощью malloc редкая ситуация, и после такой ошибки, скорее всего, невозможно полноценное функционирование программы. Но меня удивляет, с каким упорством программисты, приводя эти аргументы, предлагают вообще ничего не делать в такой ситуации. Я не призываю всех делать сложные механизмы восстановления работы после нехватки памяти или использовать заранее выделенные резервные буферы. Многим программам не нужны такие сложные механизмы. Тем не менее я не понимаю, почему хотя бы минимально не обработать такие ситуации корректно. Раз других объяснений пока не хватило, попробую в этот раз рассказать короткую притчу.
