Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
>
Почему PVS-Studio не предлагает автомат…

Почему PVS-Studio не предлагает автоматические правки кода

19 Ноя 2020

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

0776_Autoreplace_ru/image1.png

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

Причина в том, что PVS-Studio не является анализатором стиля кода. Он не предлагает изменения, связанные с форматированием или именованием. Не предлагает он (по крайней мере на момент написания статьи :) заменить в C++ коде все NULL на nullptr. Это хоть и хорошее предложение, но оно не имеет практически ничего общего с поиском и устранением ошибок.

PVS-Studio выявляет ошибки и потенциальные уязвимости. Многие ошибки заставляют задуматься и требуют изменения поведения программы. И только программист может решить, как исправить ту или иную ошибку.

Анализатор, обнаружив ошибку, скорее всего, предложит упростить код, чтобы аномалия исчезла, но это не исправит саму ошибку. Понять же, что на самом деле должен делать код и предложить осмысленное полезное исправление, очень сложно.

Рассмотрим ошибку, которую я разбирал в статье "31 февраля".

static const int kDaysInMonth[13] = {
  0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
};

bool ValidateDateTime(const DateTime& time) {
  if (time.year < 1 || time.year > 9999 ||
      time.month < 1 || time.month > 12 ||
      time.day < 1 || time.day > 31 ||
      time.hour < 0 || time.hour > 23 ||
      time.minute < 0 || time.minute > 59 ||
      time.second < 0 || time.second > 59) {
    return false;
  }
  if (time.month == 2 && IsLeapYear(time.year)) {
    return time.month <= kDaysInMonth[time.month] + 1;
  } else {
    return time.month <= kDaysInMonth[time.month];
  }
}

Анализатор понимает, что обе проверки являются истинными. Но почему, анализатору непонятно. Он ничего не знает про дни, месяцы и прочие сущности. И научить понимать такое ой как непросто. Единственное, что реально сделать - это чтобы анализатор предлагал упростить функцию:

bool ValidateDateTime(const DateTime& time) {
  if (time.year < 1 || time.year > 9999 ||
      time.month < 1 || time.month > 12 ||
      time.day < 1 || time.day > 31 ||
      time.hour < 0 || time.hour > 23 ||
      time.minute < 0 || time.minute > 59 ||
      time.second < 0 || time.second > 59) {
    return false;
  }
  if (time.month == 2 && IsLeapYear(time.year)) {
    return true;
  } else {
    return true;
  }
}

Или, чего уж мелочиться, пусть он предложит такую автоматическую замену:

bool ValidateDateTime(const DateTime& time) {
  if (time.year < 1 || time.year > 9999 ||
      time.month < 1 || time.month > 12 ||
      time.day < 1 || time.day > 31 ||
      time.hour < 0 || time.hour > 23 ||
      time.minute < 0 || time.minute > 59 ||
      time.second < 0 || time.second > 59) {
    return false;
  }
  return true;
}

Прикольно, но бессмысленно ;). Анализатор убрал код, который с точки зрения языка C++ является лишним. И только человек может понять, является код действительно избыточным (а такое тоже часто бывает), или в коде допущена опечатка и надо заменить month на day.

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

В августе этого вирусного года я написал статью о проверки библиотеки PMDK. Среди прочего в статье рассматривалась ошибка неправильной защиты от переполнения:

static DWORD
get_rel_wait(const struct timespec *abstime)
{
  struct __timeb64 t;
  _ftime64_s(&t);
  time_t now_ms = t.time * 1000 + t.millitm;
  time_t ms = (time_t)(abstime->tv_sec * 1000 +
    abstime->tv_nsec / 1000000);

  DWORD rel_wait = (DWORD)(ms - now_ms);

  return rel_wait < 0 ? 0 : rel_wait;
}

Раз переменная rel_wait имеет беззнаковый тип, то последующая проверка rel_wait < 0 не имеет смысла. Предупреждение PVS-Studio: V547 [CWE-570] Expression 'rel_wait < 0' is always false. Unsigned type value is never < 0. os_thread_windows.c 359

Кто-то воодушевился статьёй и начал массово исправлять описанные в ней ошибки: Fix various issues reported by PVS-Studio analysis.

И как же было предложено исправить код? Весьма бесхитростно: core: simplify windows timer implementation.

0776_Autoreplace_ru/image2.png

Но код был упрощен, а не исправлен! Это заметили и началась соответствующая дискуссия: ISSUE: os_thread_windows.c - get_rel_wait() will block if abstime is in the past.

Как видите, даже люди ошибаются в предложенных правках. Куда уж пытаться роботам.

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

Популярные статьи по теме
Ускоряем сборку и анализ при помощи Incredibuild

Дата: 17 Май 2021

Автор: Максим Звягинцев

"Да сколько ты ещё будешь собирать?" – фраза, которую каждый разработчик произносил хотя бы раз посреди ночи. Да, сборка бывает долгой и от этого никуда не деться. Нельзя же просто так взять и распар…
GTK: как выглядит первый запуск анализатора в цифрах

Дата: 04 Янв 2021

Автор: Святослав Размыслов

Внедрение статического анализатора в проект для некоторых людей выглядит непреодолимой преградой. Почему-то очень распространено мнение, что объём выданных результатов анализа при первом запуске наст…
Стоило ли столько ждать, чтобы найти баг?

Дата: 21 Дек 2020

Автор: Святослав Размыслов

Наверняка Вы задавались вопросом, чей код качественнее: у проекта с открытым кодом или закрытым? После прочтения нашего блога можно подумать, что все ошибки собрали проекты с открытым исходным кодом.…
Продолжение: обидно за мнения про статические анализаторы кода

Дата: 16 Окт 2020

Автор: Андрей Карпов

Планировалось, что, написав статью "Обидно за мнения про статические анализаторы кода", мы выговоримся и спокойно отпустим тему. Но неожиданно эта статья вызвала бурный отклик. К сожалению, обсуждени…
Обидно за мнения про статические анализаторы кода

Дата: 12 Окт 2020

Автор: Андрей Карпов

Инструменты статического анализа кода ушли далеко вперёд. Это вовсе не те "линтеры", которые активно применялись 20 лет тому назад. Однако многие по-прежнему относятся к ним как к очень простым инстр…

Комментарии (0)

Следующие комментарии
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять