Ядро Linux проверено статическим анализатором PVS Studio

свободный софт проверяется бесплатно, закрытый код - по платной подписке

Поддерживаю. Выглядит выгодно со всех сторон.

CppCheck

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

Вопрос обсуждён в удалённой. Вкратце: нет.

Кажется, он не проверялся даже CppCheck (хотя недавно в списке рассылки заговорили, что неплохо было бы проверить с помощью Coverity)

Кто-то его таки воткнул в Coverity Scan: https://scan.coverity.com/projects/2810, но ни одного билда не проанализировал.

Т.е. новость о том что самый эпичный баг (12309) их поделка не видит. И под наш linux оно так-же не работает.

И таки я вас спгашиваю: зачем новость про это тут?

Наверняка они свою сеть строят на основе какого ни будь опенсорсного сервера и неужели ни одна из этих компаний не захочет заплатить за ревизию своего продукта?

Так речь совсем не об этом.

Тебе сделали забесплатно, а ты вопишь что мало, ты бы не палилась так, лалка

Мне пока ещё ничего не сделали. Зато сообщество поюзали.

Как бы то не было,а мозг без спецальных реагентов хлеб и масло не работает.
Да и компьютер денег стоит.

Зато сообщество поюзали.

Каким образом?

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

А ман ты при этом прочитал, юный падаван? :)

CppCheck анализирует ровно то, что видит. Если он чего-то в коде не понимает, просто молчит. К нему можно писать .cfg files, описывающие поведение библиотек. Хорошо подходит для ловли локальных утечек ресурсов (в начале функции создали ресурс библиотечным вызовом, в конце забыли удалить), потенциальных обращений по нулевому указателю, чтению неинициализованных данных и прочих подобных ошибок.

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

Свой код я регулярно им гоняю.

Зато сообщество поюзали.

Фанатики не понимают суть учения пророка, но горло готовы перегрызть любому, кто якобы посягает на святое. Как обычно.

компания паразитирует на опенсорсе, не принося ему никакой реальной пользы

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

Кодекс Фанатика Опенсорса: если ты посмел использовать программу под свободной лицензией, но сам ничего не написал, то ты паразит.

А проверьте еще {Free,Open,DragonFly}BSD.

Проверка Linux вызвала отклик, так что я думаю мы попроверяем ещё что-то из этого мира. Кстати, интересующиеся могут познакомиться с "Обновляемый список open-source проектов, которые мы проверили с помощью PVS-Studio". Постоянно предлагают проверить одни и те-же проекты и поэтому прошу заглядывать в этот список.

Я так и не понял, что это было: пиар или таки годное дело?

Это удачное совмещение пиары и пользы. Мы проверили уже более 200 открытых проектов. Многие из них мелкие и в них была найдено всего по несколько ошибок, так что статью из этого не сделаешь. Но авторов проектов мы уведомляем, а результаты проверок находят отражение в базе ошибок. Получили немало благодарных откликов. Некоторым командам предоставили бесплатные лицензии. Так что пользу миру мы однозначно приносим.

А сам PVS-Studio проверяли при помощи PVS-Studio?

Да, мы делаем это регулярно. Ответ на этот вопрос даже внесён в FAQ для читателей наших статей. Кстати, для тех кого интересует, как мы тестируем PVS-Studio предлагаю посмотреть вот эту статью. Она немного устарела. Например, теперь по ночам исходный код PVS-Studio проверяется с помощью статического анализатора Clang. Но общую информацию статья даёт.

Исправлять то будут?

Да. Много поправлено. Но внимательно я не следил.

Так можно ли ждать PVS-Studio для Linux? ;)

Зависит от того, наберётся ли критическая масса потенциальных пользователей. Только надо понимать, что потенциальный пользователь, это не тот, кто оставляет комментарий «хочу версию под Linux» :). А те компании, с кем у нас происходят конструктивные обсуждения в почте. Такие уже есть, но масса пока не набрана.

Проверка Microsoft Word 1.1a (апрель 2014)

ну теперь я спокоен. будущее в надёжных руках

если ты посмел использовать программу под свободной лицензией, но сам ничего не написал, то ты паразит

И это правда, чистая правда.

Это не английский

Да, в этот раз альтернативный предновогодний перевод не удался. Сейчас переводим заново. Потом перевыложим на сайте.

а шо за перцы и откуда выскочили?
И если они такие крутые, то почему до сих пор не проверили реактось?

проверили :)

Проверили же.

И после таких ошибок джеди будет говорить что это говно работает????

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

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

Понимаю, что вряд ли сообщество решит скинуться хотя бы на CppCat.

Кстати, хочу напомнить миру про:

• Бесплатный CppCat для студентов
• Почему студентам нужен анализатор кода CppCat

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

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

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

программа предлагает патчи

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

Бывает и более эпическое. Был случай, когда ошибка заключалась в неправильных аргументах функции. Что-то типа такого: memset(x, sizeof(x), 0); Перепутан 2 и 3 аргумент. Первый человек пришел и поменял местами аргументы. Следующий, не посмотрев , вновь поменял. В результат получилось то, что и было. :)

Почему бы вам не сделать открытый сервис для проверки СПО вашим анализатором?

Потому, что эта большая работа по созданию и поддержке системы, польза от которой (в денежном плане) весьма сомнительна. Если вы намекаете на Coverity, то следует не забывать, что на это они регулярно получают гранты. Т.е. делают не от доброты душевной, а за то, что им платят деньги. Если нас кто-то вдруг начнёт спонсировать, мы бы тоже такое делали.

мне вот интересно, чего все так на него мастурбируют

Думаю, причина в том, что его очень легко попробовать. Просто натравил на папку с файлами и уже можно получить какой-то результат. Мне, например, Cppcheck тоже нравится. Ну а так да, он конечно явно слабее. Только прошу фанатов сдерживать эмоции. Это нормально, когда платное решение лучше, чем бесплатное. Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio

• кратко;
• пояснения.

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

Зачем удалили? Вы, уважаемый, там так с анализом налажали, что ценность вашего поделия пока под вопросом. Я уже комментировал ваши страхи по поводу strcmp. Результат этой функции может использоваться не для выяснения у кого больше, а в качестве равно/не равно. И это не ошибка. Про memset вы тоже отожгли. Вы проверили что все происходит так как вы написали? Что gcc проскипает вызов memset или это ваши страхи? Для выяснения этого вопроса нужно анализировать Makefile, что вы пока не осиливаете. У вас опыт с визуальщиной волшебным образом распространяется на gcc. Не убедительно. Анализ кода ядра так как если бы он собирался Visual Studio не интересен даже с академической точки зрения. Но пиар вы себе сделали, хреновенький правда.

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

Ценность изделия подтверждается клиентами, многие из которых уже не раз продлевают лицензию.

А по поводу страха, Вы зря. Если у вас нет паранойи, это ещё не значит, что они за вами не следят.

То, что strcmp используется для проверки равно/не равно, ничего не меняет. Предположим, что не равно и функция вернула 0x100000. Урезаем до байта и получаем 0 (равно). Если пока функция strcmp() не возвращает больших значений, это ничего не значит. Реализации strcmp() могут быть разные и меняться со временем. И в статье приводится пример, когда это не абстрактные страхи, а уязвимость.

По поводу memset(). Какая разница, как показал себя конкретный GCC с конкретными настройками? Никакой. Это уязвимость. И memset() следует заменять на memzero_explicit().

Пукан твой поюзали, судя по визгу, иди уроки учи, лалка

Откуда тебе знать чем она вызвана? Вполне может быть что дело в одной скобочке не на своём месте.

12309 - это вообще не ошибка. это заблуждение.

Откуда тебе знать чем она вызвана? Вполне может быть что дело в одной скобочке не на своём месте.

Да еще и незакрытой.

Вы ядро анализируете, у вас реализация этого memcmp перед глазами. Какие 0x100000, не несите чушь. Там разница между двумя байтами лежит, не верите так проверьте. Вы своей вижуалстудией размахиваете которая к ядру никакого отношения не имеет.

Какая разница, как показал себя конкретный GCC

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

. Ваш анализ - повод задуматься о том что вы делаете.

Они проверяют, как код ведет себя на Си-библиотеке, отвечающей стандартам.

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

Если ядро заточено исключительно под GCC, это не проблема PVS.

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

та нафиг тогда нужно такое ядро...

а вообще, по-моему, чем его только не собирали, и tcc, и pcc, и clang, и чем-то закрытым

А ман ты при этом прочитал, юный падаван? :)

Ну ты, конечно, ляпнул. Кто ж маны то на лоре читает.

CppCheck анализирует ровно то, что видит. Если он чего-то в коде не понимает, просто молчит. К нему можно писать .cfg files, описывающие поведение библиотек

Ну он вроде умеет в стандарты + Qt. А большим я и не пользуюсь обычно.

В шланге же тоже есть статический анализатор, почему с ним нет сравнений?

Они проверяют, как код ведет себя на Си-библиотеке, отвечающей стандартам.

Lol што? Ядро ведь не программка под вантуз, тут специфику понимать нужно. Понаходили уязвимостей из разряда «если бы бабушка была дедушкой». Почему не проанализировать MySQL, например. Зачем лезть туда где толку от их анализа ноль.

раз

два

Они проверяют, как код ведет себя на Си-библиотеке, отвечающей стандартам.

Lol што

Что именно тебе непонятно?

Ядро ведь не программка под вантуз, тут специфику понимать нужно

Кому нужно? PVS это явно не нужно. Тебе нужно? Ну вот и фильтруй предупреждения. Люди из PVS прогнали ядро через готовый анализатор и нашли некоторое количество подозрительных мест. Можно кривить морду и говорить «ваше говно расчитано на вижуалси», а можно просто исправить реальные ошибки. Кривить морду легче, да.

Зачем лезть туда где толку от их анализа ноль.

Вполне очевидно, что твоя квалификация не позволяет тебе об этом судить.

Люди из PVS хренью маются, лучше бы делом занялись. Эту простую мысль я и пытаюсь донести. Что толку от нахождения уязвимостей которых нет. Так понятно?

Люди из PVS хренью маются, лучше бы делом занялись.

Твое мнение рассмотрено и признано неверным.

Что толку от нахождения уязвимостей которых нет.

Смелое заявление. Думаю, его смелость вызвана либо невежеством, либо безответственностью.

В отношении ядра ОС написать такое

Они проверяют, как код ведет себя на Си-библиотеке, отвечающей стандартам

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

Вы ядро анализируете, у вас реализация этого memcmp перед глазами. Какие 0x100000, не несите чушь. Там разница между двумя байтами лежит, не верите так проверьте. Вы своей вижуалстудией размахиваете которая к ядру никакого отношения не имеет.

А почему Вы решили, что всегда используется и всегда будет использоваться такая простая реализация memcmp()? Вот здесь например «arch\s390\lib\string.c» есть такая memcmp():

int memcmp(const void *cs, const void *ct, size_t n)
{
	register unsigned long r2 asm("2") = (unsigned long) cs;
	register unsigned long r3 asm("3") = (unsigned long) n;
	register unsigned long r4 asm("4") = (unsigned long) ct;
	register unsigned long r5 asm("5") = (unsigned long) n;
	int ret;

	asm volatile ("0: clcle %1,%3,0\n"
		      "   jo    0b\n"
		      "   ipm   %0\n"
		      "   srl   %0,28"
		      : "=&d" (ret), "+a" (r2), "+a" (r3), "+a" (r4), "+a" (r5)
		      : : "cc" );
	if (ret)
		ret = *(char *) r2 - *(char *) r4;
	return ret;
}

По поводу упорствования с memset() мне тоже не понятно. https://lkml.org/lkml/2015/1/12/1069