LINUX.ORG.RU

Cppcheck 2.5

 , , ,


2

5

Вышла новая версия статического анализатора для С и С++.

В новой версии:

В парсере:

  • различные исправления;
  • теперь поддерживаются все возможности c++11, c++14, c++17;
  • частичная поддержка с++20.

Также анализатор теперь:

  • знает больше об API;
  • показывает меньше ненужных предупреждений;
  • находит больше багов;
  • исправлены вылеты и ложные срабатывания в Misra.

Добавлены новые проверки:

  • подозрительное присваивание контейнера/итератора в условии;
  • повторное пробрасывание текущего исключения с помощью throw;.

Примеры кода, которые демонстрируют новые проверки:

void f(std::string s) {
  if (s = "123") {
  }
}
Assignment in condition should probably be comparison
void func1(const bool flag) { try{ if(!flag) throw; } catch (int&) { ; } }
Rethrowing current exception with 'throw;', it seems there is no current exception to rethrow.
If there is no current exception this calls std::terminate(). More: https://isocpp.org/wiki/faq/exceptions#throw-without-an-object

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: xaizek (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Это ж только в рантайме работает. А статически?

Во-вторых, если есть uncaught exceptions, то throw точно никакого нельзя делать.

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

Воооот. Хотя, наверное, действительно trow; вне catch блока это в 90% случаев ошибка.

А в лямбде оно ругнется? Я бы мог предположить кейс, что некоторая общая часть catch блока вынесена в лямбду, которая вызывается для разных типов.

А current_exception используется сплошь и рядом при переброске результатов между потоками. Или те же futures, expected…

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

А в лямбде оно ругнется? Я бы мог предположить кейс, что некоторая общая часть catch блока вынесена в лямбду, которая вызывается для разных типов.

вот онлайн версия есть: http://cppcheck.sourceforge.net/demo/

Нет. На лямбду не ругается. Даже когда нужно: https://gcc.godbolt.org/z/deq3Y8EfW

Ну это у cppcheck ожидаемо. У них The goal is to have very few false positives, то есть лучше для них пропускать проблемы, чем сообщать о несуществующих

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

Интересно, сколько воды утечёт прежде чем Cppcheck 2.5 появится в Astra Linux и на «Эльбрусе»?

На Windows в chocolatey сегодня прилетело: https://community.chocolatey.org/packages/cppcheck

В арче пока 2.4.1: https://archlinux.org/packages/community/x86_64/cppcheck/

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

Ты когда-нибудь пробовал что-нибудь крупное на матлабе написать?

и для инженеров которым программирование не очень важно

если в предметной области уже хорошо изученные модели и есть готовые для использования тулбоксы, то да, удобно. Если надо самому с нуля что-то писать или сравнивать алгоритмы, и не так, чтобы «потерпел полгода-год, опубликовался и забыл», то язык матлаба - редкостное говно мамонта.

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

Спасибо. Наверное всё-таки пока буду на gcc полагаться. Лучше него ничего не видел (но много и не смотрел, только тот треш, что заставляют и пивас).

Gcc в последних версиях прям жжот. Много интересных косяков находит. И почти тоже без false positives.

Ну и очень неприятное - source forge у нас на работе забанен. 🤦‍♂️🤷‍♂️

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

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

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

Да, что-то типа такого и ожидалось. Надеюсь, не специально для этого кейса подкрутили? 😉

Вообще было бы интересно примеры кейсов в «современном C++» или чтобы код хоть выглядел в целом. А то у вас все статьи, которые читал, во втором абзаце содержат «после отсева пары тысяч ложно положительных»…

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

самый быстрый процессор в мире это Apple M1.

аххаххахах

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

Вообще было бы интересно примеры кейсов в «современном C++» или чтобы код хоть выглядел в целом.

Что-то похожее на это: Проверка коллекции header-only C++ библиотек (awesome-hpp) - https://habr.com/ru/company/pvs-studio/blog/524568/

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

Я считаю, что x86 уже перешёл в разряд legacy. Про прочий шлак вообще молчу. На сервере ARM лучше. На десктопе ARM лучше. На мобилках ARM лучше. На микроконтролерах ARM лучше. Для других архитектур места просто не осталось. По инерции ещё подёргаются лет 20 и всё.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Ты предлагаешь просто поверить тебе на слово? Сектант что ли?

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

ты должен был принести пруф, вместо пука в лужу

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

iPhone 8 быстрей Core i7 7700K.

Он быстрее, но только на некоторых алгоритмах. Что, собсно, уже отличный результат для мобильного процессора. Но тут есть нюанс, что 7700К — это пик загнивания менеджмента в Intel, который уже получил бодрого пинка от AMD в виде двузначного прироста IPC при смене поколений Zen. Т.е. x86 продолжает развиваться и потеснить её на серверах будет весьма непросто, ввиду огромной инерции этого рынка.

Есть ли шансы у RISC-V догнать ARM на десктопах? Есть, и весьма неплохие. При условии, конечно, заинтересованности игроков (нужна ли всем третья конкурирующая микроархитектура?). Как минимум, азиатские игроки заинтересованы в RISC-V ввиду угрозы санкционного давления на них. Так что в плане третьей микроархитектуры я склонен считать, что скорее да, чем нет.

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

@Andrey_Karpov_2020

Дарю проверку, которой у вас пока нет :)

https://godbolt.org/z/Pe46robMW

Это UB.

Комитет решил пофиксить это в С++23: https://wg21.link/P2166R1

К сожалению только в С++23, а не ко всем стандартам как Defect Report :(

Некоторые проекты сломались после этого коммита: https://github.com/microsoft/STL/commit/a8c7283e02dd65ffb375cbc38b2bfcafc066b9e1

В частности MAME, ITK, Boost, Sol2. Им уже отправлены сообщения об этом…

LLVM до 12 версии тоже имел такой баг: https://github.com/llvm/llvm-project/commit/0841916e87a39e3c223c986e8da31e4a9a1432e3#diff-01a43d7c55c7fc32700efc9923f501123ad387d913d619421e19ec1c2dd729ee

fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от Legioner

я думаю, что x86 будет долго жить, наверняка для него найдется своя ниша и он никуда не денется, но ARM определенно свой кусок пирога откусит на десктопно-серверном рынке

а через 2-3 десятка лет наверняка появится что-то еще, что и ARM подвинет

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

Это ловится компилятором. Гораздо интереснее случаи типа

char const* cs{nullptr};
string ss{cs};

Некоторые анализаторы пытаются просчитывать возможные значения на каждом этапе. Только не помню уже про кого читал статью.

Наверное тот ж pvs. У него пример очень понравился:

auto p = make_unique<char[]>();
func(move(p), p.get());

Вообще это ub из разряда «порядок вычисления аргументов не определен», но ошибка вылезает типа «сюда передается nullptr».

(Хотя если функция принимает unique_ptr&&, то это не ub, а как раз наоборот. Но возможно надо ресетить принтер, если важно, чтобы объект сдох независимо от исхода функции).

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

Некоторые анализаторы пытаются просчитывать возможные значения на каждом этапе. Только не помню уже про кого читал статью.

Скорее всего про PVS-Studio :) У нас кстати и доклад есть на тему data flow анализа: https://youtu.be/nrQUpGM9vYQ

P.S. Для заинтересовавшихся, пример с move из статьи: https://habr.com/ru/company/pvs-studio/blog/530856/

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

Это ловится компилятором.

Это не ловится компилятором в C++98, С++11, C++14, C++17, C++20. Это будет ловиться компилятором только в С++23.

Кстати, нашёл баг репорты:

https://github.com/InsightSoftwareConsortium/ITK/issues/2637

https://github.com/mamedev/mame/issues/8265

fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Это будет ловиться компилятором только в С++23.

И тем не менее будет. Да и сами авторы пропозала говорят, что это ни разу не сравнения панацея, а так, отловить Си головного мозга.

Вообще я подумал про data flow analysis: его и компилятор очень активно делает при оптимизации.

Например, было бы логично выкидывать проверку на nullptr в том же деструкторе unique_ptr (даже вместе с занулением), если заведомо известно, что в этой code branch делается move from.

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

anonymous
()

Оно конечно хорошо. Потыкал, покрутил. На моей юзер-кейсе нашел тоже самое, что и clang-tidy с скриптами. Раньше до развития clang-tidy использовал, но сейчас уже не то. Медленно развитие идет

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

Я склоняюсь к тому, что такие вещи нужны на том же уровне, что и test coverage: показать, где пробелы в тестировании (например, если опечатка есть, а тесты проходят).

Но многое даже из статьи о «современном С++ и pvs» не такое интересное. То, что функция без return statement это вообще базовый warning компилятора. Остальные (особенно с переполнением signed int) времени нет проверить.

У clang-tidy как я понимаю, есть ещё преимущество автоматического рефакторинга - то есть можно написать плагин, который определенные паттерны заменит, причем с пониманием контекста.

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

Кто вообще пишет на этом C++ где-то кроме студентов редких вузов непораженных раком (пасцалем)?

Все нормальные конторы, кроме всяких хипстеров со стартапами на час

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

на дворе 2к21

Tip of the day: Если у вас на клавиатуре не робит кнопочка 0 (ноль), то при наборе текста лучше заменяйте на букавку О.

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

А в сишке вообще нет bool, поэтому любое значение /= 0 это true, и эта хрень перекочевала в плюсы.

_Bool есть

Ровно с таким же успехом как и bool (true,false)

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

Кто вообще пишет на этом C++ где-то кроме студентов редких вузов непораженных раком (пасцалем)?

Вы не поверите, тысячи их. А вы являетесь пользователем их продуктов.

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

Я про метрическую систему. А 2к21 это что? Через 5 тысяч лет люди поймут что это значит?

Вы серьезно думаете, что кто-то через 5к лет будет перечитывать лор?

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

Зачем? Так удобно же.

В чем выражается удобство? Кроме набора слепым 10-ти пальцевым методом, другое на ум не приходит.

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

то есть по твоему получается что запись словами «две тысячи двадцать первый» == 200021? Потому что именно это там и написано.

Ну чего уж мелочиться давайте тогда 2202212 напишем, хоть на правду похоже будет в отличии от вашего 2k21.

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

Сикул сам по себе весьма-весьма-...-очень весьма ограниченная специфичная хрень. В эту долбичку *sh подошел бы куда как ближе чем sql.

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

Теоретически. На практике статический анализ (в целом) не очень умеет в тему параллельного программирования. Ну а так некоторые интересные диагностики в PVS-Studio есть. Пример - https://pvs-studio.com/ru/docs/warnings/v1036/

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

Это скорее неожиданная реентерабельность функции. Что-то типа модификации контейнера во время итерации по нему (особенно вектора). Особенно, когда вызывают колбек, который решает отрегистрироваться.

А пример с двойным локингом интересен тем, что если флаг заменить на атомик, то для x86 код абсолютно такой же сгенерируется.

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

Это скорее неожиданная реентерабельность функции.

Похоже на то, что ты плохо чувствуешь людей и не улавливаешь их истинные намерения. Карпов приперся в тему про Цэпепе чек и проталкивает свой товар под видом технической беседы. Забанить этого глупого торгаша следует и дело с концом, а не пытаться этому лысому что-то обьяснять.

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

Все правильно написали про бенефиты open source. Хотя даже если у них 14 - минимальный стандарт, с более новыми тоже надо собираться и работать уметь.

Вообще Комитет часто апеллирует к гитхабу, когда надо какие-то потенциально ломающие изменения делать.

Из последнего что ещё помню - с оператором «запятая» что-то меняли в плане перегрузки или порядка вычисления. Конечно, использовалось только в одном проекте - boost.spirit. но и то тоже в deprecated части.

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