LINUX.ORG.RU

Проект Cppcheck собирает средства для реализации улучшений

 ,

Проект Cppcheck собирает средства для реализации улучшений

2

4

Разработчик Cppcheck (Daniel Marjamäki) собирается добавить возможность верификации ПО на C и C++ в свой статический анализатор.

Верификация ПО в Cppcheck

В режиме «верификации» Cppcheck будет выдавать предупреждение, если не удастся подтвердить, что код безопасный, однако это может приводить к шуму (множественным предупреждениям).

Планы реализации

Режим верификации будет реализован последовательно. На первом этапе работа будет сконцентрирована над проверкой «деление на ноль». Это относительно простая проверка. Каждая функция будет проверяться отдельно. При этом предполагается, что все входные данные могут иметь произвольное значение. Проверки других типов неопределённого поведения будут добавлены позже. Также планируется улучшить синтаксический анализ C и C++.

Ускорение разработки

Цель сбора средств на Kickstarter — ускорение разработки режима верификации. Планируется добавить данную возможность в любом случае, но работа может занять больше времени, если средства не будут собраны. Если же средства будут собраны то Даниель сможет взять отпуск на основной работе, чтобы полностью посвятить своё рабочее время проекту cppcheck.

Цели проекта

  • Устранение ложноотрицательных срабатываний тестов деления на ноль в Juliet и ITC.

  • Исправление ложноположительного срабатывания (см. BUG#9402).

  • Улучшение анализатора C++.

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



Проверено: a1batross ()

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

Так у нас значение проинициализировнно 9.

int *i = new int(9);

Создаём int, кладём в него 9, возвращаем адрес в этого int в i.

Если что-то пошло не так, то new кидает исключение.

Не нужно там ничего проверять.

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

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

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

вы наверное какой-нибудь яндексовод? ))

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

Пивас-студио-капец? Интересное начинание, одобряю.

Если скинемся, то так оно и будет. Собственно, давно пора, пивас достал своим унылым пеаром.

ncrmnt ★★★★★
()
Последнее исправление: ncrmnt (всего исправлений: 1)
Ответ на: C - норм язык от anonymous

С как был так и остался нормальным языком

Да. В отличие от…

а вот C++ превратили в говно.

После того, как в С++17 впилили 2/3 (примерно) буста, стало ясно что в С++ особо больше нечего делать. Сишечка справляется и ладно.

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

внимательнее читайте FQA секции :D :D :D

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

Да, мы в курсе...

Ровно наоборот.

Что, ЕМНИП, Вас где-то полгода (семестр, Вы говорили, кажется?) насиловали С. Очевидна Ваша психологическая травма. Да, так бывает. Но тут не всем «системы» и «реализации» пилить. Кому-то и клея между парочкой фреймворков за глаза.

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

Так у нас значение проинициализировнно

Действительно. Виноват.

Manhunt ★★★★★
()

цели проекта научить складывать строки.

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

мне кажется его просто насиловали )))

Не знаю. Я не вникал особо.

anonymous
()
Ответ на: Да, с С++ всегда проблемы. от anonymous

Во-первых, язык сам по себе понуждает не по-детски извращаться. И тут уже дело не в том, что анализатор гуано, а в том, что код зачастую без пол-литра не разберёшь. Если следовать рекомендации «пиши проще, как на С», то тогда смысл С++ ускользает.

«Пиши проще» (с т.з. читаемости кода) - вовсе не означает «пиши как на C». Откуда вообще может появиться такая мысль?

Во-вторых. У меня лично splint подключён к vim через syntastic. Синтаксический анализ кода производится сразу при сохранении файла (можно настроить и так, чтобы при открытии производился, не проблема). И сразу формируется список ошибок (если они есть). Т.е., я сразу вижу косяки и могу их поправить до компиляции.

Ну это все понятно. По-хорошему статический анализ при использовании С++ должен быть неотьемлемой частью CI. Тут же никто не говорит, что анализаторы малополезны, потому что каждый раз IDE их запускает, и это типа время - нет, не поэтому. Проблема именно в качестве самых анализаторов и количестве ложных срабатываний. Если анализатор генерит кучу чепухи, не важно, разобьешь ли ты обработку этой чепухи на множество мелких частей, анализируемых при каждой сборке или запустишь анализатор на весь проект сразу. От перестановки слогаемых сумма не поменяется. Даже лучше разгребать авгиевы конюшни для всего проекта сразу, чем по частям - меньше переключений мозга на удовлетворение капризов анализатора.

Но это как минимум странно статическим анализатором искать ошибки, проявляющиеся в динамике.

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

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

Палка какое-то УГ

дык. больше пронхаб не оплатить :-)

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

Но основной посыл в том, что если ПО как следует протестировано, то львиная доля багов уже выловлена

Вот только стоимость ловли немного разная. Заметить как IDE подчеркнула код и исправить - секунды. Весь цикл обнаружения и исправления бага - часы, если баг несложный. И всё равно остаются дремлющие баги.

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

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

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

Rust

Че-то не работает ни хрена

error: expected `[`, found `include`
 --> src/lib.rs:1:2
  |
1 | #include <iostream>
  |  ^^^^^^^ expected `[`

error: aborting due to previous error

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

пивас достал своим унылым пеаром

Ну пеар это последнее, что меня волнует (тем более, на ЛОРе его давно не было), а вот догнать его по фичам и впрямь не помешало бы.

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

Тогда лучше уж коверити. Хотя это все мечты, мечты…

ncrmnt ★★★★★
()

Возможно вы имели ввиду PVS Studio

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

О, да. Dear PVS-Studio… помним-помним.

Закапывайте уже.

Себя закопай, толку больше будет.

hobbit ★★★★★
()

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

valgrind выручает, остальное фуфло. все эти ваши пвс-студии, шланг-тиди и т.д, всё фуфло для лохов которые не могут написать код так чтобы по нему можно было понять есть в коде проблема или нет, а потом не могут написать юнит-тест на этот код.

хотя конечно если у вас cтуденты первого курса пишут хелловорды, то может чем-то помочь конечно.

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

А не пытаются ли товарищи своими анализаторами решить проблему останова?

А valgrind хорош!

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)

Да уж лучше на Раст перейти православный, чем плюсы ковырять – попрошайки одни на плюсах, куда ни кинь.

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

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

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

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

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

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

хотите облегчу страдания? забудьте про статический анализ, не надо надувать щёки, пишите на с++ как на джаве и всё будет хорошо. писать на с++ как джаве можно было ещё на с++98. забудьте про модели памяти, забудьте про SFINAE, про auto и про всё остальное, это не для вас, делайте сразу лицо попроще. для вас скоро сделают synchronized как в джаве - пользуйтесь как в джаве.

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

хотя конечно если у вас cтуденты первого курса пишут хелловорды, то может чем-то помочь конечно.

Как-то было выступление или статья одного разраба такого вот анализатора, в котором(-ой) он приводил примеры найденных багов у клиентов. И там действительно какой-то ахтунг был, типа #define на имена функций из стандартной библиотеки. В общем, за написание такого говнокода надо наказывать, как завещал Луговский, «не от нетерпимости, а исключительно от благородного желания ударить побольнее».

seiken ★★★★★
()

Кстати, кто-нибудь пробовал scan.coverity.com на своем опенсорсном проекте? Я пытался свой хелловорлд туда отправить, скачал ихние утилиты, которые собирают результаты анализа, отправил архивчик. В статусе проекта там что-то изменилось, типа, «проверили». И всё. А где отчет-то? Там надо как-то по особому что ли свои репозиторий оформить? Ну типа файлы с инфой о лицензиях добавить? Но в факе об этом ничего не сказано.

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

valgrind выручает, остальное фуфло. все эти ваши пвс-студии, шланг-тиди и т.д, всё фуфло для лохов которые не могут написать код так чтобы по нему можно было понять есть в коде проблема или нет, а потом не могут написать юнит-тест на этот код.

Тогда уж фуфло всё. Тот-же PVS видит в valgrind вот такой мёртвый код:

static
Bool doHelperCallWithArgsOnStack (....)
{
  ....
   if (guard) {
      if (guard->tag == Iex_Const
          && guard->Iex.Const.con->tag == Ico_U1
          && guard->Iex.Const.con->Ico.U1 == True) {
         /* unconditional -- do nothing */
      } else {
         goto no_match; //ATC
         cc = iselCondCode( env, guard );
      }
   }
  ....
}

В valgrind сам в себе это не видит. https://habr.com/ru/company/pvs-studio/blog/327994/

Так что спасение только одно. Применять и то и то. Тогда недостатки одного фуфла компенсируется другим фуфлом. Вот как-то так.

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

Вы либо оба теоретики, либо у вас отдел разработки в Гаскони. Реальные разрабы делают реальные ошибки, которые (часть которых) анализаторами ловятся. И не все они тривиальные, мало ты примеров посмотрел.

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

мне эти высеры про пвс-студию на хабре напоминают фокусника показывающего дешёвые фокусы. типа нашли опечатку в коде, ого, нашли строку кода которая не вызывается, ого, прямо как будто компилятор выдал предупреждение. а если я напишу if (condition), а надо было написать if (!condition), пвс-студия это обнаружит? нет? а почему? это же статический анализатор, почему бы ему не проанализировать.

ну вот например int rgba = 0;. ну явно же с запахом код, а вдруг rgba в int не влезет, а что вообще этот программист имел ввиду когда присваивал ноль - это в четыре канала или только в первый, а что насчёт endianess, ааа? ну явно же просится сюда предупреждение пвс-студии и не одно, а лучше пять. или может даже лучше сразу переписать на русте.

по поводу всех этих опечаток и невызываемых строк надо смотреть не в пвс-студию, а в историю изменений. у гита есть такая команда blaim. а спасение очень простое: ты пишешь юнит-тест, прогоняешь его под валгриндом и смотришь, что валгринд не показал ошибок. затем ты делаешь отчёт о покрытии тестами и в этом отчёте смотришь какие ветки ты на самом деле покрыл тестом, а какие не покрыл. рекомендую открыть для себя gcov/lcov, ну и, конечно, юнит-тесты надо, сцуко, не только писать, но ещё и читать.

вот такой статический анализ.

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

Так они и задачи такой не ставят, анализировать логику программы - это же проблемой останова попахивает. Эти статические анализаторы C++ просто указывают места в программе, которые могу привести к проблемам. А могут и не привести.

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

Реальные разрабы делают реальные ошибки, которые (часть которых) анализаторами ловятся.

Тот разраб, который printf #define’ом подменил тоже реален. И что?

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

а зачем брать этот всратый недоязычек?

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

ну я ж не против. просто это подаётся под таким соусом типа «пришло спасение, нашёлся анализатор который нашёл пропущенную звёздочку».

и никого вообще не смутило, что сравнение char * и char сконпелировалось без предупреждений? а может оно сконпелировалось с предупреждением или даже с ошибкой, просто никто не проверил? а что если взять вот этот код с хабра и скопипастить его в godbolt, то что получится?

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

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

Ты клинический идиот, да? Оно перебирает все возможные последовательности выполнения в рантайме.

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

Говно этот ваш cppcheck

Кстати, вот на такой код cppcheck ругается, так что кое-что он пытается искать, но пока плохо конечно:

#include <iostream>

int main()
{
    int *i = new int(9);
    if (*i)
        std::cout << *i << std::endl;
    delete i;
    std::cout << *i << std::endl;
    return 0;
}

https://imgur.com/a/yYKPYhy

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

Да я разное видел.

«Пиши проще» (с т.з. читаемости кода) - вовсе не означает «пиши как на C». Откуда вообще может появиться такая мысль?

Встречались и такие «клованы» (даже «клоунами» назвать сложно).

По-хорошему статический анализ при использовании С++ должен быть неотьемлемой частью CI.

А отчасти так и есть. Если посмотреть на опции gcc/gpp/g++, то там уже многое сделано для защиты от дурака при компиляции. Та же поддержка fortify source или ASLR. Тот же splint для С это просто «система раннего предупреждения». Злобность системы так же настраивается. Там… большая дока на splint.

Проблема именно в качестве самых анализаторов и количестве ложных срабатываний

Splint можно ограничить в его злобности, есть такое. Можно даже предупредить что, мол, я знаю что здесь ты будешь орать, но так надо, не обращай внимания. Т.е., ответственности программиста за косяк (даже потенциальный) ни кто не снимает. Просто потому, что ни один анализатор не берётся за семантику программы. Максимум что – он может «свистнуть» типа возможен buffer overflow, например. Или переменные не инициализированы. Но ждать от него чудес… Не знаю. Не хотел бы я чтоб за меня анализатор ещё и код правил. =)))

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

Это кому как. Я проверяю автоматом, при сохранении файла сырцов. Потом, конечно, весь проект «продираю» splint’ом. Но если сразу есть «стук», то я лично сразу предпочитаю его поправить. В сумме качество кода выше получается.

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

Про флейм понятно. =) А так-то, TDD или отдельное тестирование ни кто и не отменял и не собирается. Хотя, видел я клованов, которые утверждали что безглючных проектов не бывает. Чем они заканчивали, тоже видел. =)))

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

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

Непрерывный статический анализ кода

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

Верно. Однако статический анализатор, это предварительный грубый отсев. Это грубое решето, применяемое на самом раннем этапе. Вот в чём его смысл. Можно быстро сразу найти часть ошибок. Это дешево. Можно найти их и потом, но это дороже. Хорошо и правильно про идеологию рассказывается здесь: Иван Пономарёв. Непрерывный статический анализ кода: https://youtu.be/_Wv-PvZeRlI Очень хорошее видео.

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