PVS-Studio для Linux

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 на самом деле своей предметной критикой ты им помогаешь. Игнорировать их надо.

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

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

gcc с "-Wall -O2" найдет обе.

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

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

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

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

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

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

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

Как статические ловить хз, может кто подскажет?

"-fsanitize=address"

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

Похоже что -fstack-protector-all -Wstack-protector

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

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

Похоже что -fstack-protector-all -Wstack-protector

Это другая история и тут оно не поможет.

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

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

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

но есть же valgrind

Кстати, о valgrind. Valgrind - это хорошо, но недостаточно.

А какие идеи? Надо чтобы компилятор маркеры вставлял, потом отслеживал.... Как это сделать?

Я уже написал: -fsanitize=address. Прекрасно отслеживает подобные ситуации.

ок, доказали

Благодарю, очень полезная штука

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

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

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

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

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

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

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

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

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

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

Прошу писать в поддержку.

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

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

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

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

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

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

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

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

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

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

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

void update_position(int last, int delta) {
  unsigned actual = last - delta;
  ...
}

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

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

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

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

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

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

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

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

Почему?

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

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

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

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

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

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

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

Так и понимают. Вы что-то конкретное хотите спросить?

Как это?

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

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

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

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

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

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

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

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

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

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

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) );
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Господин ерунду какую-то сморозил.

Это вы так про Дейкстру?

Диагностика сравнения вещественного числа с нулём несколько утомляет, у нас в gwyddion оно в куче мест используется для проверки, не делится ли число на ноль ровно. Может имеет смысл разбить её на сравнение с нулём и не с нулём? Ну плюс логика условий в циклах местами несколько криво детектится и получаются ложные срабатывания на неинициализированную переменную или другие предупреждения о состоянии переменных и указателей, но обычно код в этих местах достаточно кривой. А так нашлось некоторое количество проблем, часть уже исправили, другую часть постепенно смотрим.