LINUX.ORG.RU

PVS-Studio для Linux

 , , ,


0

5

Появилась версия анализатора PVS-Studio, работающая в GNU/Linux. До этого программа работала только в Windows.

PVS-Studio — это инструмент для выявления ошибок в исходном коде программ, написанных на С и C++. В случае интеграции с Visual Studio также возможна проверка проектов на C#.

PVS-Studio выполняет широкий спектр проверок кода, но наиболее удачно справляется с поиском опечаток и последствий неудачного Copy-Paste. Показательные примеры таких ошибок: V501, V517, V522, V523, V3001.

Хочу поблагодарить всех, кто принял участие в Beta-тестировании и отправлял нам свои отзывы. Эти отзывы действительно были крайне полезны. Спасибо!

Пакеты PVS-Studio в форматах deb, rpm и tgz доступны для скачивания на официальном сайте.

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

Обязательно сразу же прочитайте краткую инструкцию «как запустить PVS-Studio в Linux».

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

Доклад на конференции C++ CoreHard Autumn 2016 «Что пришлось тестировать и о чем узнать при подготовке Linux-версии PVS-Studio».

Про что доклад: большинство программистов плохо представляют, что означает создание PVS-Studio для Linux. Многие думают, что вся сложность заключается в портировании кода, однако это очень далеко от истины: портировать код очень просто, но это только 5% работы. Остальная работа скрыта от стороннего наблюдателя и состоит в решении многих инфраструктурных вопросов. Предлагаем заглянуть на кухню разработчиков анализатора PVS-Studio и узнать разные интересные нюансы их работы.

>>> Подробности

Ответ на: комментарий от newprikolist

Так у тебя gcc вместо компилятора.

anonymous ()
Ответ на: комментарий от newprikolist
int f(int i) {
  volatile char a[10];
  a[i]=10;
  (void)a;
  return 0;
}

int main(void) {
  volatile char b[10];
  f(10);
  b[10]=10;
  (void)b;
  return 0;
}

Статический анализатор в таком случае всего одну ошибку. Valgrind найдёт две, собственно его основная задача такие ошибки искать.

ASM ★★ ()
Ответ на: комментарий от ASM

ASM на самом деле своей предметной критикой ты им помогаешь. Игнорировать их надо.

А чо Пивасик-Студия хули.

anonymous ()
Ответ на: комментарий от anonymous

на самом деле своей предметной критикой ты им помогаешь.

Я знаю. Ребята только одной документацией заслужили себе уважение.

ASM ★★ ()
Ответ на: комментарий от newprikolist

А вы часто смотрите на предупреждения, когда компилируется крупная программа?

Свой код собираю только с -Werror. Потому не просто смотрю, но и не допускаю их в принципе.

anonymous ()
Ответ на: комментарий от newprikolist

Нормальные люди всегда пишут с -Werror -Wall

Обманул с valgrind, поймает только, если malloc делать. Как статические ловить хз, может кто подскажет?

ASM ★★ ()
Ответ на: комментарий от newprikolist

А к предупреждениям как относишься?

Очень хорошо, чем больше компилятор проверяет - тем меньше шансов на ошибку.

anonymous ()
Ответ на: комментарий от newprikolist

Покажите, что выдаст ваша программа?

int a[10];
a[10]=0;

V557: Array overrun is possible. The '10' index is pointing beyond array bound.

Andrey_Karpov_2009 ()
Ответ на: комментарий от pseudo-cat

Никакие ошибки найденные обсуждаемым инструментом искать нельзя. И исправлять их тожк. Ибо отЪ диавола.

Deleted ()
Ответ на: комментарий от Deleted

Никакие ошибки найденные обсуждаемым инструментом искать нельзя. И исправлять их тожк. Ибо отЪ диавола.

Отлично сказано.

ASM, послушай нас ты помогаешь врагам Свободы. Они тебе всё равно фик заплатят. Поимеют тебя как презерватив, и всё.

anonymous ()
Ответ на: комментарий от anonymous

«Они тебе всё равно фик заплатят. Поимеют тебя как презерватив, и всё.»

Друзья Свободы с рогатым демоном на эмблеме тебе платят?

anonymous ()

можно ли ответить на мой вопрос:

проанализировал проект командами:
pvs-studio-analyzer trace ...
pvs-studio-analyzer analyze ...
plog-converter ...

увидел, проблему, поправил, опять проанализировал, а проблема все еще висит
make clean и анализ убирает исправленную проблему, а иначе никак ?

x905 ★★★★★ ()
Ответ на: комментарий от x905

rm ./PVS-Studio.log && rm ./PVS-Studio.tasks && make clean && pvs-studio-analyzer trace — make && pvs-studio-analyzer analyze -l ../PVS-Studio.lic -o ./PVS-Studio.log && plog-converter -t tasklist -o ./PVS-Studio.tasks ./PVS-Studio.log

Crew ()
Ответ на: комментарий от eao197

И что вопрос не в их количестве, а в том, насколько они мешают пользователям программы

Мосье считает, что писать быдлокод нормально до тех пор, пока програмным продуктом хоть как-то можно пользоваться? А где мосье работает, дабы я продукты этой шарашкиной конторы обходил за 3 версты?

anonymous ()
Ответ на: комментарий от anonymous

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

Мосье считает, что нужно внимательно читать то, на что столь авторитетный аноним счел нужным ответить. Ошибки есть везде, вне зависимости от того, считается ли код быдлокодом или нет.

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

И вот что интересно: насколько это окупается? Грубо говоря, если потратить то же время и те же деньги на увеличение объема тестов...

Не думаю, что это можно объективно посчитать, но тут такой момент: анализатор покупается (например) на год и работать он будет, в том числе, для кода, который ещё не написан. С тестами так не (всегда) получится.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

работать он будет, в том числе, для кода, который ещё не написан

Мне кажется, вы как-то странно сформулировали свою мысль.

Мой поинт был вот в чем. Допустим, мы пишем что-то вроде:

void update_position(int last, int delta) {
  unsigned actual = last - delta;
  ...
}
Анализатор покажет, что здесь есть потенциальна проблема (впрочем, со временем все компиляторы начнут об этом предупреждать). А вот будет ли так на практике анализатор не скажет. Зато нормально написанные тесты покажут есть ли проблема или нет. И, что еще важнее, чем больше объем тестов, тем больше проблем будет выявляться в последствии, при попытках сопровождения кода.

Другое дело, что сами по себе «нормально написанные тесты» — это очень не просто и очень не дешево. Тем не менее, они показывают, что работает, а что нет.

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

Неужели они никак не отслеживают, насколько их продукт выгоден их же клиентам?

Есть подозрение, что это не особо нужно клиентам. Косвенным показателем может быть продление (или наоборот) лицензии.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от eao197

Мне кажется, вы как-то странно сформулировали свою мысль.

Почему? С тем, что «идеальные» тесты покажут больше проблем, причём без ложных срабатываний спорить смысла нет.

Я просто попробовал взглянуть на это с немного другой точки зрения, тем более, что перед глазами как раз есть пример активно развивающегося проекта. Ну и ещё такой момент: начиная с какого-то размера команды, затраты на статический анализатор становятся менее значительными.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Там по поводу продления все просто: не продлишь, не будешь пользоваться. Так что если процесс разработки заточили под анализатор, то может быть тупо дешевле продлевать, чем что-то менять.

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

Хочу спросить, как программисты понимают фразу Дейкстры: «Тестирование может быть использовано для демонстрации наличия ошибок, но никогда для их отсутствия»?

Deleted ()
Ответ на: комментарий от DarkEld3r

Почему?

Потому, что я не могу понять вот это: «работать он будет, в том числе, для кода, который ещё не написан». Как работать для того, чего еще нет?

Я просто попробовал взглянуть на это с немного другой точки зрения

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

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

Там по поводу продления все просто: не продлишь, не будешь пользоваться.

Ну да, о том и речь. Если анализатор оказался полезен - не жаль и продлить.

Так что если процесс разработки заточили под анализатор

Как это? Типа заменим тесты, ревью, валгринд и прочее одним статическим анализатором? Честно говорят, плохо себе представляю кто на такое пойти может.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Как это?

Это так, что если на всех CI в компании в build-process внедрена стадия, запускающая анализатор, проверяющая его выхлоп и рапортующая о найденных проблемах, то когда эта стадия перестает работать (бо анализатор превратился в тыкву), то с этим нужно будет что-то делать.

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

Deleted ()
Ответ на: комментарий от eao197

Как работать для того, чего еще нет?

Ну это о гипотетической ситуации когда мы можем разово выделить деньги/время на написание тестов или покупку анализатора. В этом случае, анализатор будет работать весь строк, а тесты надо будет дописывать/обновлять по мере написания нового кода. Ситуация несколько искусственная, не спорю.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от eao197

то с этим нужно будет что-то делать.

Ну может и так.

Повторюсь, представляю ситуацию несколько иначе: рапортовать о проблемах и надо и если тесты сфейлились и если валгринд проблемы нашёл и т.д. Так что анализатор будет просто ещё одним индикатором.

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

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Deleted

Все просто: если на вашем коде успешно отработал тест, то это не означает, что в коде нет ошибки. Может быть данный конкретный тест просто не в состоянии показать ее наличие. А вот если тест не проходит, то в коде есть ошибка.

Грубо говоря, пусть у нас есть код, который мы хотим покрыть тестами:

unsigned update_position(int current, int delta) {
  return current + delta;
}
И мы пишем такой тест:
TEST_CASE( "positive values", "[update_position]" ) {
  REQUIRE( 3 == update_position(1, 2) );
}
Этот тест не показывает ошибку, которая есть в коде. А вот такой тест:
TEST_CASE( "negative values", "[update_position]" ) {
  REQUIRE( 0 == update_position(1, -2) );
}
ошибку демонстрирует.

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

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

Этот тест не показывает ошибку, которая есть в коде. А вот такой тест ... ошибку демонстрирует.

а в чем здесь ошибка? Разве по правилам арифметики 1+-2 не равно -1? Почему в тесте ожидаем нуль?

Deleted ()
Ответ на: комментарий от Deleted

Разве по правилам арифметики 1+-2 не равно -1?

Вы, видимо, не имеете отношения ни к C, ни к C++. Там возвращается unsigned, в котором -1 нет. При выполнении операции (1-2) получится -1, которое для unsigned будет представлять что-то вроде 0xffff или 0xffffffff в зависимости от разрядности машины.

Почему в тесте ожидаем нуль?

Мне так захотелось :)

eao197 ★★★★★ ()
Ответ на: комментарий от CatsCantFly

Так не интересно :) Не будет кулсторей про превозмогание при портировании. Кстати, они свой код этой штукой анализировали?

slackwarrior ★★★★★ ()
Ответ на: комментарий от slackwarrior

Ну так и те кто просили версию под Linux не хотели в итоге получить «Инструмент для анализа кода написанного для Visual Studio запускаемый в среде Linux»...

anonymous ()
Ответ на: комментарий от slackwarrior

Кстати, они свой код этой штукой анализировали?

в каждой новости про сабж всплывает этот вопрос. сам то как думаешь?

vvviperrr ★★★★★ ()
Ответ на: комментарий от eao197

Там возвращается unsigned,

Я это не заметил. Спасибо, все понятно.

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.