LINUX.ORG.RU

Проверка OpenSource исходников


0

0

Стенфордский университет провел автоматизированную проверку исходного кода 31 программого продукта.
С большим отрывом победили:
Ядро Linux-2.6 (1061)
Графическая подсистема X (1681)
=)

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

★★★★★

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

>С большим отрывом победили: Ядро Linux-2.6 (1061)

Где оно там победил? По общему количеству? Не смешите меня! Оно даже в десятку не попало по коэффициенту Defects / KLOC....

MYMUR ★★★★
()

А почему они весь пэдээфник отдать без регистрации жмутся? Хотят чтобы им счётчик накрутили?

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

А иксы так вообще в хвосте плетутся....

Эх, люблю заголовки новостей на ЛОРе.... =) Один не прочитав (или прочитав, но не поняв) запостил, другой точно так же "проверил".... =)

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

Обычный пеар. Зарегишься - потенциальный покупатель.

Вообще - чё тут разошлись то? Хрен с горы опубликовал непонятные цифры по непонятным тестам. И всё - пиз*ец, на лоре буча началась. До тех пор, пока не покажут критерии тестирования и примеры (хотя бы) полученных ошибок - пусть в #опу себе запихают своё тестирование вкупе с его результатами.

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

>>Ага, а Coverity в Стэнфорде идиоты писали?

>Судя по сайту - или идиоты или продажные пеарщики-манагеры.

Ну вот, еще один выискался.

Например последний релиз 2.6.15.6 целиком посвящен ошибкам, найденным с помощью Coverity.

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

Там на раз обнаруживаются use-after-free, deadlock, double free, use-before-init, и я молчу про мелочи типа sprintf, strcpy с переменными размерами буферов, причем в настолько нетривиальных ситуациях типа RCU-locking, interrupt handlers и других.

Поискали бы в google и почитали бы на сайте, что это такое, а то так и будете выставлять себя на посмешище как bmc...

>bmc * (*) (06.03.2006 16:58:51)

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

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

Но стоит заметить, что у них отношение ошибок к правильным результатам примерно 50/50 в Linux kernel.

rtc ★★
()
Ответ на: комментарий от Sun-ch

>Угу, а винда еще куда больше оборудования поддерживает. Проведем нехитрые мат. вычисления. Допустим в винде 10е6 ошибок. Считаем пресловутый коэффициент k = 10e6/30e6 = 0.333333.... ну прям как в линаксе. Из чего делаем вывод, что винда и линакс одинаково надежны.

Слушай ну утомил уже, тебя действительно всерьёз воспринимать уже нельзя. Ты считал строки кода винды? Если ты всё таки их считал, то уверен, что ты посчитал вместе с кодом драйверов входящих в поставку виндоу$? Ну и наконец вопрос на засыпку: строки кода какой версии Микрасовт Уындоу$ ты считал?

P.S. Уындоус не поддерживает больше оборудования чем Linux поскольку большее количество драйверов идёт в комплекте с устройствами а не с ОС и M$ к разработке драйверов этих устройств не имеет никакого отношения.

Ubnormal
()

IMHO это просто PR никому не нужного кода (проверялки) никак не берут ... решили потестить что нибудь .. и на публику вывалить ...

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

>Считать количество "ошибок" на тысячу операторов - еще понятно

Это каких? Ассемблерных инструкций?

>Но считать на строки кода - маразм полнейший!!! Стили форматирования исходников разные.

А посчитать что такое метрика (K)LOC слабо было перед тем как чушь нести?

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

Впервые вижу что саныч так позорно сел в лужу.

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

>Поискали бы в google и почитали бы на сайте, что это такое, а то так и будете выставлять себя на посмешище как bmc...

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

Про посмешище - абсолютно накакать, я здесь не для имиджа.

bmc
()
Ответ на: комментарий от Sun-ch

>Угу, а винда...

emacs'ом много пользовался? начался "Параноидальный солипсизм"?

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

>Ну, я так не играю. Почему OpenBSD вниманием обделили?

деление ноль на ноль наверное %)))

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

>У виндовых драйверов - 0.01 бага на KLOC. Инсайдерская инфа.

а у вас инсайдеры у каждого железячника, который драйвер пишет? Штирлиц, вы наш ;)

AcidumIrae ★★★★★
()
Ответ на: комментарий от Sun-ch

>По закону Мерфи, именно тебе срочно прийдется зайти в этот чулан в полночь и в полной темноте.

Тогда и одних граблей достаточно ! :-)

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

>Например последний релиз 2.6.15.6 целиком посвящен ошибкам, найденным с
>помощью Coverity.

ЦЕЛИКОМ??? ты бы хоть заглянул в changelog :)
исправлено всего 4 ошибки (тест показал 1055) и при этом:

Ошибка 1:
    mm/mempolicy.c: In function 'get_nodes':
    mm/mempolicy.c:527: error: 'BITS_PER_BYTE' undeclared (first use in this function)
    mm/mempolicy.c:527: error: (Each undeclared identifier is reported only once
    mm/mempolicy.c:527: error: for each function it appears in.)

    About to retry a build with the below patch which should do the trick.
    (How did this *ever* build?)

гы, да, полюбасу найдено с помощью coverity :)
мало?
Ошибка2:
    fs/nfs/direct.c: In function 'nfs_get_user_pages':
    fs/nfs/direct.c:110: warning: implicit declaration of function 'nfs_free_user_pages'
    fs/nfs/direct.c: At top level:
    fs/nfs/direct.c:127: warning: conflicting types for 'nfs_free_user_pages'
    fs/nfs/direct.c:127: error: static declaration of 'nfs_free_user_pages' follows non-static declaration
    fs/nfs/direct.c:110: error: previous implicit declaration of 'nfs_free_user_pages' was here

LOL :))))))))))
дальше - больше

error 3:
Thanks to
    Alan and Gareth for pointing this out.

    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>

интересно, почему благодарят за найденную ошибку не Coverity? :)))

error 4:
    Thanks to Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru> for
    reporting and testing the suggested fix.

    Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>

тоже Coverity отдыхает.

так почему же, уважаемый, это "релиз 2.6.15.6 целиком посвящен ошибкам, найденным с помощью Coverity"???

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

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

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

>Интересно, как эти автоматические проверяльщики ошибки находят. Я могу >написать правильный код с точки зрения С, но с не правильной логикой, >который к примеру каждую пятницу будет убивать корневой раздел ?

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

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

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

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

Но в общем понятно. Скорее стоит воспринимать эти "ошибки" как warning'и компилятора, поскольку ни одна проверялка не может знать _зачем_ написана программа, они проверяют из некоторых модельных представлений о программе. Но представь себе, что считывание в буфер без проверки длины ввода не незамеченная ошибка, а так и было задумано. Хотя бы в качестве демонстрационного примера ;-)

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

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

> +1. При оценке надежности системы важно именно абсолютное число ошибок (приблизительная оценка абсолюного количества ошибок), а не соотношение количество ошибок/строчек кода.

Абсолютно с вами согласен, коллега. Но почему вы умалчиваете о том, что абсолютное количество ошибок интересно не само по себе, а только как аргумент вопроса "больше ли нуля абсолютное количество ошибок, или нет"?

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

>Абсолютно с вами согласен, коллега. Но почему вы умалчиваете о том, что
> абсолютное количество ошибок интересно не само по себе, а только как 
>аргумент вопроса "больше ли нуля абсолютное количество ошибок, или нет"?

пять баллов :)

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

>Но в общем понятно. Скорее стоит воспринимать эти "ошибки" как 
>warning'и компилятора, поскольку ни одна проверялка не может знать 
>_зачем_ написана программа, они проверяют из некоторых модельных 
>представлений о программе. Но представь себе, что считывание в буфер 
>без проверки длины ввода не незамеченная ошибка, а так и было задумано.
> Хотя бы в качестве демонстрационного примера ;-)

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

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

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

Вы воспринимаете coverity как простую проверялку, обнаруживающую использование опасных функций. Это не так. Coverity обнаруживает существенно больше ошибок, это отнюдь не подсказки, что буфер может быть переполнен, а действительно ошибки, такие как двойное освобождение памяти, взаимные блокировки, использование памяти до инициализации и после освобождения и т.п.

http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=1&s=coverity&a...

>anonymous_incognito

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

> так почему же, уважаемый, это "релиз 2.6.15.6 целиком посвящен ошибкам, найденным с помощью Coverity"???

Для 2.6.16.6 надо полагать. double kfree in gss_krb5_wrap. br_nf_post_routing null check.

>Man

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

Потому что, после просмотра сравнительных результатов Open, Free и Linux кое-кто сделал бы как Томми ;)

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

Ну 0.4 это хоть и "почти" каждая 2-я строчка - зато 0.333... это уже "наверняка" в каждой 3-й строчке есть ошибка :)))))

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

> 2.6.15.7

на текущий момент такой версии ядра еще нет 

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

> Для 2.6.16.6 надо полагать. double kfree in gss_krb5_wrap. 
> br_nf_post_routing null check.

это где ты такое нашел?

2.6.16-rc5 на kernel.org самое последнее из testing. выше 2.6.15.6 стабильных еще нет (2006-03-07 18:50)

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