Comments 44
4261 багрепортов на халяву… Вот наверно парни образовались =)
Менеджмент обрадовался, программисты не очень :)
Это не совсем багрепорты в обычном их понимании. Coverity делает репорты потенциально опасных мест в коде разного уровня опасности, там еще можно выставлять что можно игнорировать, а на что обращать внимение. IMHO этот аудит был со всеми включеными правилами.
Вообще, Coverity достаточно неплохой инструмент в этом плане. Многие крупные компании используют для аудита своего кода, достаточно много интересного можно найти этим свежим «взглядом».
Вообще, Coverity достаточно неплохой инструмент в этом плане. Многие крупные компании используют для аудита своего кода, достаточно много интересного можно найти этим свежим «взглядом».
А я думал, что в php будет намного больше ошибок. Хотя, будь их даже в разы больше, любить я этот фиолетовый грузовик не перестану :)
интересно, по какой технологии проводили автоматизированное тестирование?
… и сколько багов в нем самом. :D
В статье есть линк на Coverity: www.coverity.com/development-testing/index.html
А какой 5.3, интересно, имеется в виду? 5.3.0, 5.3.3 или 5.3.10? Потому что в 5.3.9 была самая мощная дыра за всю историю php. Причем, насколько помню, пробралась она в заплатке, коей латали другую дыру в 5.3.8. Т.е. не факт, что 5.3.10 чист.
5.3.6, 5.4.0 как минимум
echo 0x00+2;
4
echo 0x00+ 2;
2
лексер писали кривожопые мудаки, не прочитавшие за всю жизнь ни одной умной книжки, кроме букваря и может быть библии для детей, да и те невнимательно.
бессмысленно говорить о «качестве кода»
echo 0x00+2;
4
echo 0x00+ 2;
2
лексер писали кривожопые мудаки, не прочитавшие за всю жизнь ни одной умной книжки, кроме букваря и может быть библии для детей, да и те невнимательно.
бессмысленно говорить о «качестве кода»
ребят, минусующие, внимательно посмотрите на те 2 строки кода, которые я привёл. это 0x00+2 и 0x00+ 2 (это 0 в шестнадцатиричной системе плюс 2, разница между ними — в пробеле)
нормально написанный лексический анализатор такой ошибки не сделает. никак. никогда. это первый класс цпш.
чтение SICP вероятность такой ошибки сводит к нулю
нормально написанный лексический анализатор такой ошибки не сделает. никак. никогда. это первый класс цпш.
чтение SICP вероятность такой ошибки сводит к нулю
Ошибки свойственны всем, если в коде есть ошибка, не значит что писали его «кривожопые мудаки». Или в Ваших программах нет ни одной ошибки после выхода? Неужели есть? Так может и Вы «кривожопый мужак» в таком случае? Уверен у каждого была хоть одна _простая_ ошибка после выхода программы в свет.
не передергиваете, пожалуйста, и не приписывайте мне того, чего я не говорил.
я не говорил о «любых ошибках». потому что ошибки бывают разные. можно написать j вместо i или перепутать меньше с больше — это бывает, и с этим по большому счёту ничего не сделать.
но можно покрыть тестами. ну, или попытаться покрыть. да, иногда такая ошибка пролезет в production. ничего страшного. ошибка исправляется, в идеале пишется ещё тест, на практике тест может и не писаться, но в любом случае ничего ужасного не произошло.
но у нас другая ситуация
есть конкретный баг: bugs.php.net/bug.php?id=61095
есть конкретная строка-багфикс: lxr.php.net/xref/PHP_TRUNK/Zend/zend_language_scanner.l#1527
ещё из университетского курса я знаю, что чтение числа из строки нужно выносить в функцию. и что гораздо лучше взять стандартную функцию, а не писать свою, потому что это на самом деле сложно, много вариантов и легко ошибиться.
собственно, мелкая ошибка в реализации — это ерунда. есть большая ошибка — своя реализация. причём человек, который это делал, не сел и не набросал на листочке граф состояний, как это стоило бы сделать, а написал цикл с костылями. костыли расставлены неверно, поэтому баг и ещё один костыль.
php -r '$s = 2; echo 0x00+4e1;' => 1289
php -r '$s = 2; echo 0x00 + 4e1;' => 40
детский сад, штаны на лямках.
я не говорил о «любых ошибках». потому что ошибки бывают разные. можно написать j вместо i или перепутать меньше с больше — это бывает, и с этим по большому счёту ничего не сделать.
но можно покрыть тестами. ну, или попытаться покрыть. да, иногда такая ошибка пролезет в production. ничего страшного. ошибка исправляется, в идеале пишется ещё тест, на практике тест может и не писаться, но в любом случае ничего ужасного не произошло.
но у нас другая ситуация
есть конкретный баг: bugs.php.net/bug.php?id=61095
есть конкретная строка-багфикс: lxr.php.net/xref/PHP_TRUNK/Zend/zend_language_scanner.l#1527
ещё из университетского курса я знаю, что чтение числа из строки нужно выносить в функцию. и что гораздо лучше взять стандартную функцию, а не писать свою, потому что это на самом деле сложно, много вариантов и легко ошибиться.
собственно, мелкая ошибка в реализации — это ерунда. есть большая ошибка — своя реализация. причём человек, который это делал, не сел и не набросал на листочке граф состояний, как это стоило бы сделать, а написал цикл с костылями. костыли расставлены неверно, поэтому баг и ещё один костыль.
php -r '$s = 2; echo 0x00+4e1;' => 1289
php -r '$s = 2; echo 0x00 + 4e1;' => 40
детский сад, штаны на лямках.
А про MariaDB что-то сказано там?
А что про него вспоминать? Слон и работает как слон. Неторопливо и надежно.
Неторопливо? А что из бесплатного работает быстрее? («Вы просто не умеете его готовить» (с) )
Неторопливо != ненадежно. Неторопливо == 'отлично исполняющий свои обязанности'
P.S. Готовить вроде умею "Интернет-магазин: стопор с архитектурой таблицы с товарами".
P.S. Готовить вроде умею "Интернет-магазин: стопор с архитектурой таблицы с товарами".
Я вот задумался, может попробовать перевести проекты на PostgreSQL. В принципе использую PDO, SQL-код локализован, большой сложности быть не должно.
На самом деле совсем не все так просто. В php PDO для PostgreSQL — очень дырявая штуковина. Когда запустили её в продакшене — просто офигели. В результате пришлось писать обвертку над нативными функциями PostgreSQL чтобы она была похожа на PDO.
Потому очень не советую использовать PDO с PostgreSQL. Для mysql он действительо «почти идеален», но для PostgreSQL — это смерть.
Потому очень не советую использовать PDO с PostgreSQL. Для mysql он действительо «почти идеален», но для PostgreSQL — это смерть.
Интересно было бы по-подробнее узнать про дыры в PDO для PostgreSQL.
Вы знаете я сейчас деталей не вспомню. Но Вот какие приключения были. Основная проблема там не просто в Postgre а в PgBouncer + PDO. Основная проблема в неправильном управлении подключениями, что приводило к различным приколам — то память текла, то Too many connections. Мы уже грешили на postgre думали что это «очередная хрень на которую мы себя сами посадили», но админ стойко стоял что все отлично настроено и работает, что у него есть другие проекты где питон не чувствует никакого дискомфорта.
После чего я в надыбал статейку о том, что это проблемы нетранзакционного режима. Началось копание в эту сторону. В итоге мы перевели весь сайт на транзакционный режим. В результате неплохо выиграли в скорости и вроде даже и помогло с проблемами. Но они всплыли позже. Все теже проблемы но на большем количестве подключений.
После чего начали копать в сторону возможности багов в PDO и как выяснилась ситуация там совсем не такая как в MysqlPDO. Для постгреса он свежий, совсем тепленький. И много кто жаловался на связку PgBouncer + PDO.
В результате поступили так, как я писал выше — переписали все на нативные функции.
Потому совет всем кто соберется переходить на постгре — используйте только функции pg_*, ни в коем случае не PDO. И чем раньше вы в проекте его начнете использовать тем больше выгоды получите. Если вы собираетесь просто перекидывать субд с одной на другую — то скорее всего выгоды будет мало. Но если «тщательно обработать напильником», то можете получить результаты в хороший плюс.
После чего я в надыбал статейку о том, что это проблемы нетранзакционного режима. Началось копание в эту сторону. В итоге мы перевели весь сайт на транзакционный режим. В результате неплохо выиграли в скорости и вроде даже и помогло с проблемами. Но они всплыли позже. Все теже проблемы но на большем количестве подключений.
После чего начали копать в сторону возможности багов в PDO и как выяснилась ситуация там совсем не такая как в MysqlPDO. Для постгреса он свежий, совсем тепленький. И много кто жаловался на связку PgBouncer + PDO.
В результате поступили так, как я писал выше — переписали все на нативные функции.
Потому совет всем кто соберется переходить на постгре — используйте только функции pg_*, ни в коем случае не PDO. И чем раньше вы в проекте его начнете использовать тем больше выгоды получите. Если вы собираетесь просто перекидывать субд с одной на другую — то скорее всего выгоды будет мало. Но если «тщательно обработать напильником», то можете получить результаты в хороший плюс.
Если нет четких критериев, почему нужно переходить на PostgreSQL, то лучше не стоит. PDO под PostgreSQL в PHP не так давно появился, что бы можно было записать в разряд «стабилен для продакшена».
А если не PDO и ясно, в чем профиты будут от PostgreSQL в проекте, то да. Лично я PDO не использую в принципе, а плюшки в духе RETURN, PLProxy, schema (создание на основании namespace-ов класса в PHP) очень лично для меня полезные, поэтому и юзаю PostgreSQL. Но это на абсолютно нулевом проекте, проекты с историей тянуться на MySQL.
А если не PDO и ясно, в чем профиты будут от PostgreSQL в проекте, то да. Лично я PDO не использую в принципе, а плюшки в духе RETURN, PLProxy, schema (создание на основании namespace-ов класса в PHP) очень лично для меня полезные, поэтому и юзаю PostgreSQL. Но это на абсолютно нулевом проекте, проекты с историей тянуться на MySQL.
Мне кажется, или Coverity передирает у PVS-Studio маркетинговые идеи?
Особенно рад за php, если честно, не ожидал…
И что мы будем делать с linux 2.6? Уже 3.4-rc5 на дворе…
и там весь старый код выкинули?
Нет, не весь. Но если они смотрели, например 2.6.32, то между ним и современными версиями проходит огромное количество изменений. cgroups, отказ от глобальных блокировок критических секций (== переписана куча драйверов), куча изменений в управлении памятью и т.д.
С точки зрения актуальности это исследование для 3.3, например, имеет весьма спорную ценность. Хотя, конечно, обрадует пользователей 2.6.18, 2.6.32 и 2.4.16, которые теперь с чистой совестью смогут перейти на «свежее» ядро.
С точки зрения актуальности это исследование для 3.3, например, имеет весьма спорную ценность. Хотя, конечно, обрадует пользователей 2.6.18, 2.6.32 и 2.4.16, которые теперь с чистой совестью смогут перейти на «свежее» ядро.
А что, linux 3.4-rc5 оно уже не linux 2.6?
$ aptitude show linux-image-2.6-amd64
<..>
Version: 3.2+43
$ cat /etc/issue
Debian GNU/Linux wheezy/sid
А без регистрации нельзя ознакомиться с отчетом?
«Серьезные» клиенты все равно до сих пор смотрят на Postgre как на НЁХ, им подавай Oracle или MSSQL на худой конец. Переубедить сложно.
> средний размер тестируемых проектов составлял 832 000 строк.
> число ошибок на тысячу строк кода, который составил в среднем 0.45.
>Средний размер проекта — 7.5 млн строк кода
> средняя плотность дефектов составила 0.64.
из чего можно прийти к какому-то из двух выводов:
1. проприетарный код хуже открытого
2. число ошибок растёт нелинейно при росте кода
по-моему, 2.
> число ошибок на тысячу строк кода, который составил в среднем 0.45.
>Средний размер проекта — 7.5 млн строк кода
> средняя плотность дефектов составила 0.64.
из чего можно прийти к какому-то из двух выводов:
1. проприетарный код хуже открытого
2. число ошибок растёт нелинейно при росте кода
по-моему, 2.
Выводы не взаимоисключающие.
отнюдь.
если мы придём ко второму выводу, то из опубликованных данных мы уже не сможем сделать первый вывод.
авторы отчёта (вы же прочли сам отчёт, прежде чем стали спорить?) с этим вообще не парятся и пишут
Based upon the sample of active projects in Coverity Scan, we found the quality of open source software is above average. This is based upon a measure of defect density against the industry average defect density for the software industry.
но сделать второй вывод придётся. потому что довольно сложно иначе объяснить, что
а) в ядре линукса defect density в три раза выше, чем в postgresql и php
б) у исходников ядра линукса, postgresql и php — у всех superior code quality
если мы придём ко второму выводу, то из опубликованных данных мы уже не сможем сделать первый вывод.
авторы отчёта (вы же прочли сам отчёт, прежде чем стали спорить?) с этим вообще не парятся и пишут
Based upon the sample of active projects in Coverity Scan, we found the quality of open source software is above average. This is based upon a measure of defect density against the industry average defect density for the software industry.
но сделать второй вывод придётся. потому что довольно сложно иначе объяснить, что
а) в ядре линукса defect density в три раза выше, чем в postgresql и php
б) у исходников ядра линукса, postgresql и php — у всех superior code quality
Ну как посмотреть.
В рамках треда на Хабре/ЛОРе/* достаточно заявить, что из того факта, что число ошибок растёт нелинейно при росте кода, не следует, что оно растёт именно как f(832000)=374, f(7500000)=4800. Возможно, у проприетарных программ f(832000)=457 (0.55 на тысячу строк кода, что всё равно даёт нелинейный рост).
С точки зрения же более-менее строгого обоснования из опубликованных данных вообще ни один из этих выводов сделать нельзя, поскольку это средняя температура по больнице, причём непонятно, какая выборка и какое именно среднее. Может, там один проект был, у которого на тысячу строк две сотни ошибок приходится, потому что язык выразительный и кодеры из Полинезии.
В рамках треда на Хабре/ЛОРе/* достаточно заявить, что из того факта, что число ошибок растёт нелинейно при росте кода, не следует, что оно растёт именно как f(832000)=374, f(7500000)=4800. Возможно, у проприетарных программ f(832000)=457 (0.55 на тысячу строк кода, что всё равно даёт нелинейный рост).
С точки зрения же более-менее строгого обоснования из опубликованных данных вообще ни один из этих выводов сделать нельзя, поскольку это средняя температура по больнице, причём непонятно, какая выборка и какое именно среднее. Может, там один проект был, у которого на тысячу строк две сотни ошибок приходится, потому что язык выразительный и кодеры из Полинезии.
Sign up to leave a comment.
Linux 2.6, PHP 5.3 и PostgreSQL 9.1 признаны открытым ПО с высоким качеством кода