Компания Coverity (http://www.coverity.com/), известный производитель инструментария статического анализа кода, опубликовала (http://www.coverity.com/html/press/coverity_open_source_inte...) очередное исследование (http://scan.coverity.com/report/Coverity_White_Paper-Scan_Op...), основанное на анализе 11 миллиардов строк кода из 280 проектов СПО, включая Firefox, Linux, PHP, Ruby и Samba.
Один из выводов - целостность, качество и уровень безопасности открытого кода повышаются. С 2006 года, когда было проведено первое исследование, с помощью сервиса автоматической проверки кода (http://scan.coverity.com/) было выявлено более 11 тыс. уязвимостей в 280 предоставленных программах, что дало возможность разработчикам исправить недочёты. Coverity обнаружила, что количество ошибок, обнаруженных статическим анализом, в целом уменьшилось на 16 процентов, а общее количество ошибок снизилось от одной на 3333 строки до одной на 4,000 строк кода.
Coverity разбив...URL: http://www.coverity.com/html/press/coverity_open_source_inte...
Новость: http://www.opennet.me/opennews/art.shtml?num=23560
Хм. Оказывается, возросшее количество находимых ошибок символизирует не то, что код стал хуже, а что сообщество лучше ищет ошибки!
так и кодовая база тоже растет, ни так ли?
Я о том и хотел сказать, что увеличение количества найденных ошибок связано не с тем, что новый код хуже, а в том, что ищут лучше.
>Хм. Оказывается, возросшее количество находимых ошибок символизирует не то, что код стал хуже, а что сообщество лучше ищет ошибки!тоесть качество ошибок растет
это радует
похоже они пиарят свою систему путём прогонки ей над OpenSource
но интересно, не уж проприетарчики пользуются услугами подобных компаний, разве не проще просто не проверять, всё равно ни кто не знает
Вы можете с ними списаться, заслать им свой код, они проверять и
250 страничный отчёт пришлют, ещё год курить можно выдавая начальству
по 20 багов в месяц за победоносно найденые, устраненные и описанные. :)Обычно не более 100.000 строк, но у меня 45.000 тока взяли. :(
Дешевле с точки зрения поддержки найти такие ошибки на этапе разработки.
> но интересно, не уж проприетарчики пользуются услугами подобных компаний, разве не проще просто не проверять, всё равно ни кто не знаетпользуются подобным совтом. Не проще ибо цена бага в продакшене очень велика. Дешевле купить систему проверки кода и постоянно гонять ее по проекту + фиксать ВСЕ замечание выдвинутые проверкой.
зашлите им код qt
интересно скоко в ней автомат машина найдет глюком ))
Мало... Глючит не Qt, а новый KDE. Qt работает лучше и быстрее предыдущей версии.
отправте как тест от группы опеннет (с)
вот и узнаем
и под ошибками подразумевалось скоко плохого кода найдет ихний "автомат машина"
а не как реально работает qt
какие-нибудь бесплатные\открытые проекты есть? не нужно ссылок на поисковик, нужено мнение, основанное на личном опыте.
благодарю.
Для C++ ничего вменяемого нет. Бесплатные тулзы обычно столько ложных срабатываний делают, что через некоторое время на все эти варнинги забиваешь.
Кстати, в отчете упомянута проблема:> ...
> struct tun_struct *tun = __tun_get(tfile);
> struct sock *sk = tun->sk;
> unsigned int mask = 0;
>
> The unusual situation in this particular defect is that the misbehavior happened at compile time. gcc looked at the assignment to sk, which used tunas if it was guaranteed to be a valid non-NULL pointer, and decided that there was no point in performing the if (!tun) test below. The if() block was
optimized out. It’s in the source code, but it is NOT in the machine code that the compiler output. The programmers included a test to check
whether tun was valid, and return an error if it was not. The compiler removed that test, resulting in binaries that would allow processing to continue
past the intended checkpoint, even when tun’s value was invalid.
> ...Вот тут-то и конец статическому анализу исходных текстов. Нужен еще проект по анализу соответствия полученного машинного кода исходному :)
struct sock *sk = tun->sk;
Вот эта штука уже ошибка, т.к.если tun указывает в null, то в релизной версии эта конструкция может вызывать неопределенное поведение. Нормальный инструмент покажет, что указатель нигде не проверяется перед использованием. Так что все нормально.
> struct sock *sk = tun->sk;
> Вот эта штука уже ошибка,Там в исходном коде, якобы, есть проверка на ноль. Но она была удалена компилятором, т. к. он был уверен, что в этом месте ноль не может быть никогда.
Да и вообще можно было бы иметь функцию
struct sock* tun_get_sk(...);
Ведь они там такой же подход использовали, но для другой структуры.
Проверка на ноль там позже. Ошибка в адресации должна возникнуть до этой проверки.
> Наиболее распространёнными проблемами, обнаруживаемыми на протяжении нескольких лет, всё ещё являются нулевые указатели, утечки ресурсов и неумышленное игнорирование вычисленных значений.Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф, такие баги будут находить пачками.
> Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф, такие баги будут находить пачками.А, ну да, в яве "утечки ресурсов" официально ошибками не являются. Только вот это не выход из ситуации.
> игнорирование вычисленных значений.
а это что за монстр? printf() вместо (void)print()?
>> Наиболее распространёнными проблемами, обнаруживаемыми на протяжении нескольких лет, всё ещё являются нулевые указатели, утечки ресурсов и неумышленное игнорирование вычисленных значений.
>Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф,
>такие баги будут находить пачками.Как будто в Java-программах не может быть утечек памяти.