Приближается 2018 год и пора подумать о новых направлениях развития нашего статического анализатора PVS-Studio. Сейчас наибольший интерес для нас представляет поддержка языка Java. Дополнительно мы рассматриваем возможность поддержки языка IBM RPG. Не менее интересно развить анализ C, C++ C# кода в направлении выявления потенциальных уязвимостей. Ещё нам хочется поддержать анализ C и C++ кода на платформе macOS, и, наконец, доделать поддержку компиляторов от компаний Keil и IAR. Никуда мы не денемся и от поддержки стандарта MISRA. Перечислено много, и на всё одного 2018 года нам не хватит. Поэтому давайте вместе с нами пообсуждаем наши планы и выберем самые приоритетные направления.
Для начала напомню уже реализованные возможности статического анализатора кода PVS-Studio:
- Выявление широкого спектра ошибок и потенциальных уязвимостей в коде программ на языке C, C++, C++/CLI, C++/CX и C#.
- Удобная и простая интеграция с Visual Studio 2010-2017. Возможен автоматический анализ отдельных файлов после их перекомпиляции.
- Запуск из командной строки для проверки всего решения: позволяет интегрировать PVS-Studio в ночные сборки, чтобы утром у всех был свежий лог. Как вариант, используя утилиту BlameNotifier, можно рассылать письма разработчикам об ошибках, которые PVS-Studio нашел во время ночного прогона.
- Отличная масштабируемость. Поддержка многоядерных и многопроцессорных систем с настройкой количества используемых ядер. Поддержка IncrediBuild.
- Интерактивная фильтрация результатов анализа (лога) в окне PVS-Studio: по коду диагностики, по имени файла, по включению слова в текст диагностики.
- Большое количество вариантов интеграции в проекты, разрабатываемые под Linux.
- Mark as False Alarm – разметка в коде, чтобы не ругаться конкретной диагностикой в конкретном фрагменте файла. Также можно использовать комментарии специального вида для подавления предупреждений, относящихся к макросам.
- Mass Suppression – позволяет подавить все старые сообщения, чтобы анализатор выдавал 0 срабатываний. К подавленным сообщениям всегда можно вернуться позже. Возможность безболезненно внедрить PVS-Studio в существующий процесс разработки и сфокусироваться на ошибках только в новом коде.
- Автоматическая проверка на наличие новых версий PVS-Studio (как при работе в IDE, так и при ночных сборках).
- Использование относительных путей в файлах отчета для возможности переноса отчета на другую машину.
- CLMonitoring – проверка проектов, у которых нет файлов Visual Studio (.sln/.vcxproj); если вдруг вам не хватит функциональности CLMonitoring, то вы можете интегрировать PVS-Studio в любую Makefile-based систему сборки вручную. Аналогичная утилита под Linux носит название pvs-studio-analyzer.
- Возможность исключить из анализа файлы по имени, папке или маске; возможность проверять файлы, модифицированные за последние N дней.
- Интеграция с SonarQube. Это открытая платформа для обеспечения непрерывного контроля качества исходного кода.
- HTML отчет в коротком и полном варианте. Полный вариант включает в себя исходный код файлов и позволяет осуществлять по ним навигацию.
Поддерживаемые языки и компиляторы:
- Windows. Visual Studio 2017 C, C++, C++/CLI, C++/CX (WinRT), C#
- Windows. Visual Studio 2015 C, C++, C++/CLI, C++/CX (WinRT), C#
- Windows. Visual Studio 2013 C, C++, C++/CLI, C++/CX (WinRT), C#
- Windows. Visual Studio 2012 C, C++, C++/CLI, C++/CX (WinRT), C#
- Windows. Visual Studio 2010 C, C++, C++/CLI, C#
- Windows. MinGW C, C++
- Windows/Linux. Clang C, C++
- Linux. GCC C, C++
Мы кратко перечислили то, что уже есть. Подробности можно найти в документации. Теперь давайте посмотрим, что может появиться в новых версиях.
Потенциальные уязвимости (weaknesses), CWE
Анализатор PVS-Studio уже умеет выявлять большое количество потенциальных уязвимостей (weaknesses). Скоро появится версия PVS-Studio, где большинству предупреждений будет соответствовать тот или иной идентификатор согласно классификации CWE.
Рисунок N1. Включен столбец CWE.
Однако это только первый этап, который мы сделаем в уходящем 2017 году. В следующем году нас ждёт более интересная работа, связанная с реализацией поиска потенциальных уязвимостей. Мы планируем сделать несколько специализированных диагностик для C, C++ и C# в этом направлении. Для примера, приведём описание одной из запланированных диагностик.
Приведу описание из issues-трекера.
Для начала нам надо ввести понятие «ненадёжные данные». Это данные, которые приходят извне. Примеры ненадёжных данных:
- данные в буфере, прочитанные с помощью функции fread
- данные в буфере, полученные с помощью функции recv
- данные в буфере (строке), прочитанные с помощью scanf("%s", ...)
- целочисленная переменная, прочитанная с помощью fscanf("%i", ...)
- целочисленная переменная, прочитанная с помощью fread(&integer, sizeof(int), 1, file)
- целочисленная переменная, прочитанная из потока: wcin >> n;
- целочисленная переменная, полученная извне другими способами: n = GetFileSize(h, x);
- для получения информации используются функции GetServerVariable, ReadClient (считывается какое-то поле из структуры EXTENSION_CONTROL_BLOCK)
- и так далее
Переменная/буфер считается ненадёжным источником, пока для него не выполняется какая-то проверка значений. Примеры проверок, делающих данные достоверными (данные проверены и корректны):
- if (n == 2)
- if (strcmp(s1, s2) > 0)
- if (strchr(s1, 'c') == 0)
- if (n > 1 && n < 100)
Примечание 1. При этом проверка на NULL для указателей не считается за проверку корректности данных:
char s[100];
scanf("%s", s);
if (s) // Здесь мы ничего не проверили.
// Это вообще лишний код. 's' по-прежнему недостоверный буфер.Примечание 2. Потребуется особый механизм Data Flow для массивов и структур, которого пока нет в PVS-Studio. Дело в том, что проверка отдельных элементов не делает достоверным весь буфер/структуру. Пояснение:
unsigned char B[2];
if (B[0] < 3) // Проверяем первый элемент, но не второй.
// Второму элементу мы не можем доверять.
// Требуется реализовать для массивов "множество
// непроверенных/проверенных значений".
if (B[0] < 3 && B[1] < 3) // Проверили весь массив.
// Теперь весь массив считается достоверным.Самое сложное — подумать над вот такими проверками всего массива:
int A[100];
...
for (i = 0; i < 100; ++i)
if (A[i] < 10) // проверяем весь массив
return;Когда PVS-Studio начнёт знать о недостоверных данных, сделать диагностику, обнаруживающую их использование. Это позволит выявлять уязвимости. Много реальных уязвимостей связано с тем, что принятый байт/байты используются без предварительной проверки. Под использованием понимаются, например, такие действия:
- if (pinter[unsafe_int] == 1)
- malloc(unsafe_int * sizeof(float))
- ptr += unsafe_int;
- if (A[unsafe_buffer[1]] == 1)
- memcpy(a, b, unsafe_buffer[i])
- buffer_size = 1 + unsafe_int;
- printf(unsafe_buffer, 1, 2);
- sprintf(normal_bug, unsafe_buffer, 1, 2);
- и т.д.
Примечание 3. Такие функции, как strncpy или _tcsncpy_s (имеется в виду вариант функции с 3 аргументами), могут образовывать строку без терминального нуля в конце. Такие строки небезопасны с точки зрения применения к ним в дальнейшем функций, которые ждут на вход null-терминальную строку. Например, их нельзя передавать в функцию strlen.
Java
Уже пару месяцев тихо и спокойно ведётся разработка Java анализатора. К сожалению, пока это происходит в фоновом режиме, так как на всё не хватает сил. Рассказывать про это начинание пока рано. Отмечу только, что для Data Flow анализа планируется использовать наработки, реализованные в ядре С++ анализатора.
Java-анализатор взаимодействует с C++ ядром при помощи Java Native Interface (JNI). Для генерации обёрток над функциями используется SWIG (Simplified Wrapper and Interface Generator). Это позволяет переиспользовать функционал C++ анализатора, а также повысить производительность.
Чтобы подогреть интерес, приведу пару ошибок, которые уже умеет выявлять PVS-Studio в Java-коде.
Проект JMonkeyEngine. Предупреждение PVS-Studio: V6004 The 'then' statement is equivalent to the 'else' statement. VRMouseManager.java:139, 147
if( environment.isInVR() == false ){
Texture tex = environment.getApplication().
getAssetManager().loadTexture(texture);
mouseImage.setTexture(
environment.getApplication().getAssetManager(),
(Texture2D)tex, true);
ySize = tex.getImage().getHeight();
mouseImage.setHeight(ySize);
mouseImage.setWidth(tex.getImage().getWidth());
mouseImage.getMaterial().getAdditionalRenderState().
setBlendMode(BlendMode.Alpha);
mouseImage.getMaterial().getAdditionalRenderState().
setDepthWrite(false);
} else {
Texture tex = environment.getApplication().
getAssetManager().loadTexture(texture);
mouseImage.setTexture(
environment.getApplication().getAssetManager(),
(Texture2D)tex, true);
ySize = tex.getImage().getHeight();
mouseImage.setHeight(ySize);
mouseImage.setWidth(tex.getImage().getWidth());
mouseImage.getMaterial().getAdditionalRenderState().
setBlendMode(BlendMode.Alpha);
mouseImage.getMaterial().getAdditionalRenderState().
setDepthWrite(false);
}В приведённом коде блоки then и else одинаковы. Стоит проверить код на наличие ошибки, либо убрать дублирование.
Проект RxJava. Предупреждение PVS-Studio: V6022 Expression 'idx3 > 0' is always true. JavadocWording.java:865
if (idx1 > 0 && idx2 > 0 &&
(idx3 < 0 || (idx2 < idx3 && idx3 > 0))) {
....
}Возможно настоящей ошибки здесь нет, но проверка idx3 > 0 является избыточной. Раз idx2 > 0, и idx2 < idx3, то idx3 всегда будет больше нуля.
IBM RPG
Далеко не все знают, что это за язык, поэтому начнём с его краткого описания.
IBM RPG (Report Program Generator) — язык программирования, синтаксис которого был изначально сходен с командным языком механических табуляторов компании IBM. Был разработан для облегчения перехода инженеров, обслуживавших эти табуляторы, на новую технику и переноса данных. Первоначально был реализован для IBM 1401. Широко использовался в 1960-х и 1970-х.
Рисунок 2. IBM 1401. См. также Ken Ross and Paul Laughton demo the IBM 1401.
Компания IBM продолжает поддержку языка и в настоящее время, так как на нём написан громадный объём кода, который невыгодно переводить на другие языки программирования.
В версии RPG IV, выпущенной в 2001 году, введены элементы объектного программирования.
Компилятор Visual RPG, разработанный сторонним производителем, обеспечивает работу под Windows и поддержку GUI. Существуют также реализации для OpenVMS и других, более экзотических платформ.
Подробнее о языке можно прочитать в Wikipedia: IBM RPG. Плюс, мы скоро планируем написать обзорную статью про этот язык.
Теперь надо рассказать, почему мы обратили внимание на этот язык.
С нами связалась компания, потенциально заинтересованная в статическом анализе кода на языке RPG. Поэтому мы решили посмотреть на этот язык, и он нас заинтересовал. Как мы понимаем, на этом языке написано много кода, который нужно поддерживать и дописывать новые фрагменты. При этом специалистов, знакомых с этим языком, крайне мало, что заставляет думать о дополнительных способах контроля его качества и корректности. Именно из этого и возникает интерес к возможности статического анализа кода.
Мы подумали, что раз в мире продолжают появляться и развиваться анализаторы для таких языков, как Cobol и Ada, то почему-бы нам не сделать анализатор для RPG. Тем более, что этот язык пока обделён в плане анализаторов кода. Например, существует анализатор SonarRPG, но в нём реализовано только 8 диагностик для выявления ошибок. Этого явно недостаточно. Я уверен: мы бы смогли предложить пользователям гораздо больше интересных диагностик для выявления настоящих ошибок и опечаток.
Мы не спешим браться за создание анализатора для IBM RPG, но решили озвучить эту тему, чтобы поискать потенциальных клиентов. Если в вашей организации имеют дело с IBM RPG, то мы будем рады пообщаться с вами и узнать ваше мнение о перспективах разработки RPG-анализатора.
Если мы увидим, что к языку RPG действительно есть интерес, то в 2018 мы начнём работу в этом направлении.
Примечание. Анализатор IBM RPG, если такой появится, будет поставляться отдельно и иметь специальную цену (винтаж ведь дороже стоит :).
Рисунок N3. Книги по языку RPG куплены. Осталось найти героя их прочитать.
macOS
Предлагаем делать предзаказы и приобретать лицензии на macOS версию анализатора.
На данный момент macOS версия не готова, но в её создании нет ничего сложного. Нужно просто взять и сделать её. Думаю, если этот вопрос станет актуальным, мы адаптируем PVS-Studio для macOS в течение нескольких месяцев. Другое дело, что пока мы не торопимся это делать. Мы не уверены, что это более приоритетное направление, по сравнению с другими.
Поэтому мы были бы рады продать несколько лицензий, чтобы убедиться в практическом интересе со стороны программистского сообщества.
Нам важен именно практический интерес, а абстрактный интерес мы «уже проходили» и сделали неудачный продукт CppCat :). Хочется не повторять таких ошибок.
Преимущества, которые получат клиенты, приобретя ещё неготовую PVS-Studio:
- За цену годовой лицензии Вы сможете использовать PVS-Studio 2 года.
- Вы получите интеграцию именно под свою сборочную систему и окружение.
Keil, IAR
Компании Keil и IAR разрабатывают компиляторы для встраиваемых систем. Время от времени нам пишут с предложением реализовать их поддержку. Никаких препятствий нет и часть работы уже проделана. К сожалению, не хватает ресурсов довести это до ума и протестировать. Надеюсь, мы сможем найти время для Keil и IAR в 2018 году.
MISRA
До недавнего времени мы крайне узко смотрели на стандарт MISRA с позиции — как много ошибок он позволит найти. Это неправильный подход. Смысл таких стандартов как MISRA не в том, чтобы найти как можно больше ошибок в проекте. Их смысл, чтобы дополнительно контролировать качество кода и предостерегать программиста от использования потенциально опасных конструкций языка.
Например, одно из правил MISRA запрещает использовать оператор goto. Если взять и попробовать применить такое правило к старому, большому, и при этом давно существующему проекту, то результатом, скорее всего, будет разочарование от такой проверки кода. Почти наверняка, не найдется ошибок, зато придётся переписывать большое количество алгоритмов, чтобы избавиться от goto. Этим можно нанести больше вреда, чем получить пользы, случайно внеся ошибки в процессе рефакторинга кода.
Стандарт MISRA используют не так. Приложение сразу должно писаться с учетом приведённых в стандарте правил. Образно говоря, MISRA не способ борьбы с существующими goto, а способ, чтобы эти goto не использовались при написании кода.
Мы пересмотрели своё отношение к стандарту MISRA и понимаем, что он действительно необходим, хоть и не укладывается в нашу модель «взяли большой проект, запустили PVS-Studio, нашли ошибки». Наши потенциальные клиенты хотят одновременно и использовать MISRA и находить опечатки, которые замечательно выявляет PVS-Studio.
Мы идём навстречу нашим клиентам и начали работу по поддержке стандартов MISRA C и MISRA C++ в PVS-Studio. По умолчанию MISRA-предупреждения будут отключены. Мы не хотим забивать окно отчета такими сообщениями, как «нельзя использовать комментарии /* */, следует использовать //». Однако, в любой момент набор MISRA-диагностик можно будет включить и начать регулярно использовать.
Заключение
Как видите, на 2018 год у нас очень много планов. Эта статья написана как повод начать дискуссию с нашими новыми потенциальными пользователями и узнать, что больше их интересует. Просим проявлять активность и писать нам свои мнения по озвученным направлениям. Особенно веским словом будут предзаказы лицензий :).
Всем спасибо за внимание и заранее поздравляем с наступающим Новым 2018 годом!
Комментарии (76)
robert_ayrapetyan
14.12.2017 22:02Есть ли шанс отвязаться от strace?
Целый пласт «linux-подобных» платформ остается за бортом из-за этого.
SvyatoslavMC
14.12.2017 22:20Утилита strace не является основой работы анализатора в Linux, а всего лишь инструмент для одного из режимов запуска. Есть другие способы проверки CMake/QMake проектов, а прямая интеграция анализатора в сборочную систему вообще не имеет ограничений в использовании, т.к. занимает соседнее место с компилятором в системе.
robert_ayrapetyan
14.12.2017 22:28А можно поподробнее о режимх запуска, не требующих strace? Проект CMake.
SvyatoslavMC
14.12.2017 22:36Конфиг/сборка:
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=On <src-tree-root> make -j8
Анализ:pvs-studio-analyzer analyze -l /path/to/PVS-Studio.lic -o /path/to/project.log -e /path/to/exclude-path -j<N>
Генерация отчёта:plog-converter -a GA:1,2 -t tasklist -o /path/to/project.tasks /path/to/project.log
О всех параметрах анализа и генератора отчётов — тут.
robert_ayrapetyan
14.12.2017 22:41Вообщем сейчас все получилось, непонятно почему не работало раньше. Спасибо!
TNV
16.12.2017 16:36А для Windows как cmake проекты анализировать?
SvyatoslavMC
16.12.2017 16:40Все не Visual Studio проекты в Windows проверяются с помощью утилиты Standalone.
TNV
17.12.2017 15:17А есть возможность делать анализ с помощью json файла, как это приведено в примере выше для linux? Как я понял отслеживание с помощью Standalone не дает 100% срабатывания.
SvyatoslavMC
17.12.2017 15:22Сам CMake поддерживает JSON Compilation Database для ограниченного списка проектов. В Windows я Вам рекомендую просто сгенерировать проект для Visual Studio и проверить плагином.
robert_ayrapetyan
14.12.2017 22:37Если следовать инструкции с сайта, то вот что я получается:
pvs-studio-analyzer analyze -j2 -o PVS-Studio.log
Error: Couldn't open file strace_outSvyatoslavMC
14.12.2017 22:46На вход можно подать как strace_out, так и compile_commands.json. По умолчанию эти два файла ищутся в текущей директории запуска, но вы можете задать другое имя с помощью параметра командной строки.
VAAKAraceGUM
14.12.2017 23:40Умеет ли PVS-Studio, хоть в каком-то виде, анализировать контекст происходящего в коде?
1. Если ДА, то хотелось бы видеть в Вашем продукте ряд проверок, направленных на анализ многопоточного кода. Абстрактно размышляя, количество объектов и методов синхронизации конечное множество, при этом, довольно, малое. Поиск параллельных участков кода и данных, с которыми имеют дело этот код — задача, достаточно, тривиальная. И при этом, количество диагностик, которые можно было бы написать в этой области достаточно большое (учитывая именно статический анализ кода, естественно, что покрывается не все и поэтому без valgrind и sanitaizer-ов не обойтись). Так же Ваш любимый CWE-362: Race Condition.
2. Так же хотелось бы видеть интеграцию со сборочными решениями уровня Enterprise (как единой точки входа для анализа) и иными IDE (в качестве полноценных плагинов) где это поддерживается, например, CLion/IntelliJ IDEA(в будущем), чтобы не править CMake файлы сборки.
Спасибо.
Andrey2008 Автор
14.12.2017 23:41Касательно пункта 1.
Такие проверки появятся. В конце концов когда-то был неудачный VivaMP. Так что опыт есть. Только теперь мы будем делать не для OpenMP я для распространённых библиотек распараллеливания. Не делаем мы это по той причине, что по-настоящему хорошо всё равно не получится. И пока мы отдаём предпочтение другим направлениям.
Хорошо не получится по той причине, что поиск параллельных ошибок это ооочень сложная задача для статических анализаторов кода. В своё время Intel потратил много сил на разработку статического анализатора для поиска параллельных ошибок. Вы слышали про этот статический анализатор? Вот тот-то и оно, что нет. Не получилось и проект свернули. Если не получилось у Intel, я не уверен, что получится у нас.
VAAKAraceGUM
15.12.2017 01:20Я с Вами соглашусь, и даже скажу, что статически анализом абсолютно невозможно решить целые классы задач в области параллельного кода, однако, мой опыт работы со множеством параллельных математических, научных библиотек и опыт работы с иными библиотеками, где есть какой-то параллельный код показывает, что программисты, зачастую, делают абсолютно простейшие ошибки при написании такого кода, можно даже глубоко не лезть.
Для статического анализа подойдут такие простейшие проверки:
1. Внутри потока все исключения, которые могут произойти должны перехватываться.
2. Явный вызов join() или detach() после порождения потока далее по контексту (STL only).
3. Передача значения по ссылке std::cref() если оно не изменяется в потоке или далее по контексту выполнения.
4. Использование lock_guard() и unique_lock() c объектами синхронизации (не везде).
5. Использование scoped_lock() если надо заблокировать несколько объектов синхронизации.
И т.д.
Статический анализ свое место под солнцем может завоевать.
Maccimo
15.12.2017 01:41Java-анализатор взаимодействует с C++ ядром при помощи Java Native Interface (JNI).
Какие задачи будет решать java-часть и почему решили не делать всё на родном для вас C++?
Andrey2008 Автор
15.12.2017 09:33Не всё. Просто механизм Data Flow анализа большой, сложный и есть смысл его переиспользовать.
EgorBredikhin
15.12.2017 11:03Для прототипа мы решили использовать дерево и семантическую модель из spoon, т.к это позволяет существенно ускорить разработку.
Поэтому и сами диагностические правила также пишутся на Java.
NeoCode
15.12.2017 09:14Логичнее всего конечно Java (вроде один из самых популярных языков), и Objective C (раз уж вы решили таки выйти на MacOS).
Штуки типа RPG кажутся весьма экзотическими, я не уверен что даже здесь есть кто-то, кто встречал это название до прочтения этой статьи. Такое надо под заказ делать… утром деньги вечером стулья, но деньги вперед:)
zone19
15.12.2017 10:41Не смотрели в сторону нотификаций вида: а вот этот код-то можно в современном стандарте улучшить? Первый претендент — «Вот у этой виртуальной функции можно поставить override, что позволит избежать ошибок в дальнейшем» и т.п.?
Andrey2008 Автор
15.12.2017 10:46Это всё очень размывает функцию поиска ошибок, которую мы считаем основной. Вот, например, можно рекомендовать менять NULL на nullptr. Вроде бы простая, хорошая рекомендация. Но в большом проекте, подобные предупреждения превратят отчёт анализатора в тыкву.
zone19
15.12.2017 10:56Ну и скажем честно, NULL менять на nullptr не так уж и полезно. Я не сталкивался за свою практику с ошибками, которые бы решились такой заменой. В отличие от разъехавшихся сигнатур виртуальных функций, или огроменный бинд на boost, который можно заменить на красивую лямбду.
hdfan2
15.12.2017 12:16Я не сталкивался за свою практику с ошибками, которые бы решились такой заменой.
Элементарно:
#include <stdio.h> void func(void *) { printf("ptr"); } void func(int) { printf("int"); } void main() { func(NULL); // WTF?! Why "int", not "ptr"?! }
Но проблема действительно не сильно частая.zone19
15.12.2017 13:18Выглядит как проблема C, где нет ссылкок и модифицируемые переменные любят передавать по указателю. В C++ чаще все-таки передают ссылки, видимо это здорово ограничивает полезность.
AndreyMtv
15.12.2017 10:42Раз уж поддержку джавы планируете, то может и котлин захватите по дороге?
Популярность котлина будет только расти со временем.
genI3
15.12.2017 10:47+4Как минимум, я лично, буду очень рад поддержке RPG. В RDi очень не хватает статического анализатора. Да, в RDi 9.6 появились некоторые наметки на простейший рефакторинг, но этого очень мало.
Rampage
15.12.2017 13:55+1+1 за RPG. (правда с обязательным условием поддержки разных нотаций 4 и free.)
EvgeniyRyzhkov
15.12.2017 14:13Не понял про free — поясните, пожалуйста.
genI3
15.12.2017 14:23Имеется в виду free-form RPG, пример тут.
EvgeniyRyzhkov
15.12.2017 14:41Фуф, free-form мы знаем, это ладно. А то у меня аллергия на слово free — вот и мерещится всякое.
vvzvlad
15.12.2017 14:08нельзя использовать комментарии /* */, следует использовать //
А почему?hdfan2
15.12.2017 14:43Тем, что можно забыть закрыть комментарий, и случайно закомментарить код:
/* Comment Some_Critical_Function(); /* another comment */
Также из-за этого запрещены /* внутри комментариев.firk
15.12.2017 15:52Ну вообще подсветка синтаксиса эти проблемы сразу убирает. Хотя можно предположить ситуацию, когда при мердже двух независимых коммитов в какую-нить vcs получится такая ситуация и подсветку там уже никто не посмотрит.
Сам стараюсь использовать наоборот // чтобы компилировалось с -std=c89
Kyoki
15.12.2017 15:36А планируется ли к V2001 и подобным добавить диагностику о использовании анси функций винапи вместо юникодовских?
Andrey2008 Автор
15.12.2017 15:38Приобретайте лицензию, и мы сделаем такую диагностику :). Для этого и существует набор "Реализовано по запросам пользователей".
Andrey2008 Автор
15.12.2017 17:04Уже 9 человек проголосовали за IBM RPG. Я и не рассчитывал на такой ажиотаж. Я конечно надеялся, что статья «найдёт своего читателя». А их уже девять. :)
Прошу откликнуться всех, кто голосовал за RPG. Давайте пообщаемся.
devalone
17.12.2017 15:03Сделайте бесплатную версию для open-source проектов.
SvyatoslavMC
17.12.2017 15:27На данный момент только так: Как использовать PVS-Studio бесплатно
devalone
17.12.2017 16:51А если у меня в проекте в каждом файле вначале идёт информация о лицензии? Могу ли я добавить комментарии после неё, например так?
// Flamingo is an open-source cross platform program for learning languages
// Copyright (C) 2017 Sergey Zakharov
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program. If not, see <http://www.gnu.org/licenses/>.
//
// This is an open source non-commercial project. Dear PVS-Studio, please check it.
// PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com
Или нужно именно в начале файла перед лицензией?SvyatoslavMC
17.12.2017 20:23Комментарии должны быть в начале файла. Для их добавления в автоматическом режиме в той заметке есть ссылка на специальную утилиту.
vlivyur
17.12.2017 15:28Доброе утро
Как использовать PVS-Studio бесплатноdevalone
17.12.2017 15:37Доброе. Не знал об варианте. Да, он позволяет использовать бесплатно, но не всем захочется добавлять комментарии в начало каждого файла.
Andrey2008 Автор
17.12.2017 19:24Если не хочется, то предлагаем рассмотреть вариант приобретения лицензии.
vlsinitsyn
18.12.2017 01:59Если нужна помощь с RPG — обращайтесь. 15 лет опыта c AS400 (RPG, CL и все вокруг).
Начинал на RPG || :-).
Только не простое это будет дело, я так думаю.
Фактически, RPG сегодня — это 3 (или даже 4, как считать) разных диалекта.
Я как-то пытался написать синтаксис для VIM и быстро заскучал :-).
alan008
А анализ C# уже довели до уровня С++? Или C# просто не позволяет так сильно косячить? :)
Из предложений конечно хочется Джаву, на ней же живет весь Энтерпрайз, особенно забугорный. Золотая жила для вас. Но Java как и C# не позволяет очень уж косячить.
А вместо CWE-предупреждений (полезность которых для большинства простых смертных сомнительна) я бы предложил создать класс предупреждений о потенциально тормозных операциях (возможно что-то такое у вас уже есть, просто я не знаю). Т.е. какие-то предупреждения "как не нужно писать код, потому что будет работать медленно".
Andrey2008 Автор
Мы называем это микрооптимизации. См. диагностики с номерами 8xx. Их пока немного, но постепенно будем пополнять.
alan008
Микрооптимизации — это здОрово, но сэкономить на них получится если они находятся в коде, который вызывается миллионы раз в секунду. А бывает по ошибке сделали в цикле открытие-закрытие файла или еще какую-нибудь ерунду (например, выделение больших кусков памяти, которые потом не используются). Конечно не совсем понятно, как "понять", что подразумевалось на самом деле, но попытаться выявить подобные ситуации можно. Обычно это делается на основе статистики профилирования и оптимизации конкретного проекта — выявляются проблемы, если проблема часто повторяется — придумывают способ, как ее выявлять.
Andrey2008 Автор
В этом направлении мы и работаем.
Примеры:igor_suhorukov
Для java есть множество бесплатных и качественных статических анализаторов кода: в составе sonar, findbug, huntbug и т.п. В чем будет преимущество вашего в количественном и качественном выражении?
Andrey2008 Автор
findbug мёртв (последняя версия — 6 марта 2015 года).
sonar — использовали в одном из проектов. Не впечатлил.
В общем, есть смысл попробовать.
EvgeniyRyzhkov
И да, мы знаем про IntelliJ IDEA…
igor_suhorukov
Вы так и не привели аргументов, сравнения и тп. Смысл пробовать ясен. Скорее вам нужно внедрять то что есть в новые ниши. Просто для java все отлично со статическим код анализом.
Тем более странно слышать такой отзыв о sonar от сотрудника компании, которая получает прибыль за счёт интеграции с сонаром m.habrahabr.ru/company/pvs-studio/blog/315422
huntbugs вполне доступен из maven/gradle/ant.
Для open source проектов удобно использовать в travis CI
about.sonarcloud.io
Для коммерческих — купить платную версию сонара с расширенным возможностями или использовать бесплатную в корпоративной сети.
У меня позитивный опыт использования статического анализатора java кода в Sonar в нескольких организациях
EgorBredikhin
SonarLint, например, молчит на втором примере из статьи:
На мой взгляд, Data Flow анализ в нем слабый. Явно слабее того, что мы можем предоставить уже сейчас.
Кроме того, механизм аннотаций не развит. Не находятся ошибки такого типа:
Подобные ошибки часто допускают из-за опечаток и упускать их точно не стоит.
При этом, без предварительной настройки, SonarLint уж очень сильно «шумит».
Также, у нас есть ряд уникальных диагностик в C++ и C# анализаторах, которые будут перенесены в анализатор Java.
Короче говоря, конкурентные преимущества будут.
igor_suhorukov
Спасибо за пример! В любом случае с удовольствием почитаю публикацию про новый анализатор! На Пинк удобно использовать sonar. Sonarlint при настройке подключения к сонару использует правила и настройки с сервера и не «шумит». continuous code quality дополняется code review и совсем уж ахтунг не должен пройти в эксплуатацию ПО.