Стенфордский университет провел автоматизированную проверку исходного кода 31 программого продукта.
С большим отрывом победили:
Ядро Linux-2.6 (1061)
Графическая подсистема X (1681)
=)
Вообще - чё тут разошлись то? Хрен с горы опубликовал непонятные цифры по непонятным тестам. И всё - пиз*ец, на лоре буча началась. До тех пор, пока не покажут критерии тестирования и примеры (хотя бы) полученных ошибок - пусть в #опу себе запихают своё тестирование вкупе с его результатами.
>Судя по сайту - или идиоты или продажные пеарщики-манагеры.
Ну вот, еще один выискался.
Например последний релиз 2.6.15.6 целиком посвящен ошибкам, найденным с помощью Coverity.
Когда Coverity только создавался, они рассказывали, на основе какой математической модели построен данный софт, именно из-за выбранной модели у них очень маленький процент ошибок.
Там на раз обнаруживаются use-after-free, deadlock, double free, use-before-init, и я молчу про мелочи типа sprintf, strcpy с переменными размерами буферов, причем в настолько нетривиальных ситуациях типа RCU-locking, interrupt handlers и других.
Поискали бы в google и почитали бы на сайте, что это такое, а то так и будете выставлять себя на посмешище как bmc...
>Когда Coverity только создавался, они рассказывали, на основе какой математической модели построен данный софт, именно из-за выбранной модели у них очень маленький процент ошибок.
Но стоит заметить, что у них отношение ошибок к правильным результатам примерно 50/50 в Linux kernel.
>Угу, а винда еще куда больше оборудования поддерживает. Проведем нехитрые мат. вычисления. Допустим в винде 10е6 ошибок. Считаем пресловутый коэффициент k = 10e6/30e6 = 0.333333.... ну прям как в линаксе. Из чего делаем вывод, что винда и линакс одинаково надежны.
Слушай ну утомил уже, тебя действительно всерьёз воспринимать уже нельзя. Ты считал строки кода винды? Если ты всё таки их считал, то уверен, что ты посчитал вместе с кодом драйверов входящих в поставку виндоу$? Ну и наконец вопрос на засыпку: строки кода какой версии Микрасовт Уындоу$ ты считал?
P.S. Уындоус не поддерживает больше оборудования чем Linux поскольку большее количество драйверов идёт в комплекте с устройствами а не с ОС и M$ к разработке драйверов этих устройств не имеет никакого отношения.
>Поискали бы в google и почитали бы на сайте, что это такое, а то так и будете выставлять себя на посмешище как bmc...
Возможно это так, возможно существует долгая и поучительная история создания сей тузлы, но я её не знаю. Честно говоря если на самом сайте производителя, опубликовавшем результаты тестирования нет никаких линок на то как и что проводилось - у меня совсем не возникает тяги искать что-либо в инете (и не надо утверждать, что я ламер и у меня руки из *опы ростут).
Про посмешище - абсолютно накакать, я здесь не для имиджа.
>Например последний релиз 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"???
Интересно, как эти автоматические проверяльщики ошибки находят. Я могу написать правильный код с точки зрения С, но с не правильной логикой, который к примеру каждую пятницу будет убивать корневой раздел ?
>Интересно, как эти автоматические проверяльщики ошибки находят. Я могу >написать правильный код с точки зрения С, но с не правильной логикой, >который к примеру каждую пятницу будет убивать корневой раздел ?
а он синтаксис С и не проверяет, он проверяется компилятором, и раз твой
код компилируется, то он уже правильный с точки зрения синтаксиса С
а такие системы анализируют то, как ты используешь буфферы, указатели и
прочий гемо..ой, на основе чего и делают вывод о наличии ошибок. но это
только в двух словах и далеко не все, если хочешь узнать больше,
спроси у google
> а такие системы анализируют то, как ты используешь буфферы, указатели и прочий гемо..ой, на основе чего и делают вывод о наличии ошибок. но это только в двух словах и далеко не все,
Но в общем понятно. Скорее стоит воспринимать эти "ошибки" как warning'и компилятора, поскольку ни одна проверялка не может знать _зачем_ написана программа, они проверяют из некоторых модельных представлений о программе. Но представь себе, что считывание в буфер без проверки длины ввода не незамеченная ошибка, а так и было задумано. Хотя бы в качестве демонстрационного примера ;-)
Пример, конечно, крайний, наверное в большинстве случаев предупреждения об ошибках, действительно стоят внимания, но и как истину воспринимать не следует, подобно результатам автоматической проверки орфографии и синтаксиса литературного текста.
> +1. При оценке надежности системы важно именно абсолютное число ошибок (приблизительная оценка абсолюного количества ошибок), а не соотношение количество ошибок/строчек кода.
Абсолютно с вами согласен, коллега. Но почему вы умалчиваете о том, что абсолютное количество ошибок интересно не само по себе, а только как аргумент вопроса "больше ли нуля абсолютное количество ошибок, или нет"?
>Абсолютно с вами согласен, коллега. Но почему вы умалчиваете о том, что
> абсолютное количество ошибок интересно не само по себе, а только как
>аргумент вопроса "больше ли нуля абсолютное количество ошибок, или нет"?
пять баллов :)
>Но в общем понятно. Скорее стоит воспринимать эти "ошибки" как
>warning'и компилятора, поскольку ни одна проверялка не может знать
>_зачем_ написана программа, они проверяют из некоторых модельных
>представлений о программе. Но представь себе, что считывание в буфер
>без проверки длины ввода не незамеченная ошибка, а так и было задумано.
> Хотя бы в качестве демонстрационного примера ;-)
правильно, это и есть одно из слабых мест таких систем. система
в данном случае дает слабинку в том, что не знает предметной области
и не принимает ее во внимание
>Пример, конечно, крайний, наверное в большинстве случаев предупреждения об ошибках, действительно стоят внимания, но и как истину воспринимать не следует, подобно результатам автоматической проверки орфографии и синтаксиса литературного текста.
Вы воспринимаете coverity как простую проверялку, обнаруживающую использование опасных функций. Это не так. Coverity обнаруживает существенно больше ошибок, это отнюдь не подсказки, что буфер может быть переполнен, а действительно ошибки, такие как двойное освобождение памяти, взаимные блокировки, использование памяти до инициализации и после освобождения и т.п.
> Для 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)