Как стать автором
Обновить

Комментарии 44

4261 багрепортов на халяву… Вот наверно парни образовались =)
Менеджмент обрадовался, программисты не очень :)
Это не совсем багрепорты в обычном их понимании. Coverity делает репорты потенциально опасных мест в коде разного уровня опасности, там еще можно выставлять что можно игнорировать, а на что обращать внимение. IMHO этот аудит был со всеми включеными правилами.
Вообще, Coverity достаточно неплохой инструмент в этом плане. Многие крупные компании используют для аудита своего кода, достаточно много интересного можно найти этим свежим «взглядом».
А я думал, что в php будет намного больше ошибок. Хотя, будь их даже в разы больше, любить я этот фиолетовый грузовик не перестану :)
качество кода != качество языка
да ладно?
я думал что брейнфак самый крутой язык, так как в его интерпретаторах зачастую совсем нет багов!
интересно, по какой технологии проводили автоматизированное тестирование?
… и сколько багов в нем самом. :D
А какой 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

лексер писали кривожопые мудаки, не прочитавшие за всю жизнь ни одной умной книжки, кроме букваря и может быть библии для детей, да и те невнимательно.
бессмысленно говорить о «качестве кода»
ребят, минусующие, внимательно посмотрите на те 2 строки кода, которые я привёл. это 0x00+2 и 0x00+ 2 (это 0 в шестнадцатиричной системе плюс 2, разница между ними — в пробеле)

нормально написанный лексический анализатор такой ошибки не сделает. никак. никогда. это первый класс цпш.
чтение 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

детский сад, штаны на лямках.
А про MariaDB что-то сказано там?
НЛО прилетело и опубликовало эту надпись здесь
А что про него вспоминать? Слон и работает как слон. Неторопливо и надежно.
Неторопливо? А что из бесплатного работает быстрее? («Вы просто не умеете его готовить» (с) )
Сорри, подумал, что претензии к скорости.
Тогда получается тавтология, так как «надёжно» — то же самое. Неторопливо — именно медленно, я первый раз слышу это слово в таком значении.
Все просто, важен контекст. А это слон. Многим кажется, что слон эта такая массивная неповоротливая махина. Опять же, их часто показывают мирно пасущимися на лужайке. И это правда, но не вся. А соль в том, что он может бежать со скоростью порядка 40 км/ч. Этот аспект как раз и обыгрывается.
Я вот задумался, может попробовать перевести проекты на PostgreSQL. В принципе использую PDO, SQL-код локализован, большой сложности быть не должно.
На самом деле совсем не все так просто. В php PDO для PostgreSQL — очень дырявая штуковина. Когда запустили её в продакшене — просто офигели. В результате пришлось писать обвертку над нативными функциями PostgreSQL чтобы она была похожа на PDO.
Потому очень не советую использовать PDO с PostgreSQL. Для mysql он действительо «почти идеален», но для PostgreSQL — это смерть.
Интересно было бы по-подробнее узнать про дыры в PDO для PostgreSQL.
Вы знаете я сейчас деталей не вспомню. Но Вот какие приключения были. Основная проблема там не просто в Postgre а в PgBouncer + PDO. Основная проблема в неправильном управлении подключениями, что приводило к различным приколам — то память текла, то Too many connections. Мы уже грешили на postgre думали что это «очередная хрень на которую мы себя сами посадили», но админ стойко стоял что все отлично настроено и работает, что у него есть другие проекты где питон не чувствует никакого дискомфорта.
После чего я в надыбал статейку о том, что это проблемы нетранзакционного режима. Началось копание в эту сторону. В итоге мы перевели весь сайт на транзакционный режим. В результате неплохо выиграли в скорости и вроде даже и помогло с проблемами. Но они всплыли позже. Все теже проблемы но на большем количестве подключений.
После чего начали копать в сторону возможности багов в PDO и как выяснилась ситуация там совсем не такая как в MysqlPDO. Для постгреса он свежий, совсем тепленький. И много кто жаловался на связку PgBouncer + PDO.
В результате поступили так, как я писал выше — переписали все на нативные функции.

Потому совет всем кто соберется переходить на постгре — используйте только функции pg_*, ни в коем случае не PDO. И чем раньше вы в проекте его начнете использовать тем больше выгоды получите. Если вы собираетесь просто перекидывать субд с одной на другую — то скорее всего выгоды будет мало. Но если «тщательно обработать напильником», то можете получить результаты в хороший плюс.
Спасибо! Буду иметь ввиду.
Если нет четких критериев, почему нужно переходить на PostgreSQL, то лучше не стоит. PDO под PostgreSQL в PHP не так давно появился, что бы можно было записать в разряд «стабилен для продакшена».

А если не PDO и ясно, в чем профиты будут от PostgreSQL в проекте, то да. Лично я PDO не использую в принципе, а плюшки в духе RETURN, PLProxy, schema (создание на основании namespace-ов класса в PHP) очень лично для меня полезные, поэтому и юзаю PostgreSQL. Но это на абсолютно нулевом проекте, проекты с историей тянуться на MySQL.
Мне кажется, или Coverity передирает у PVS-Studio маркетинговые идеи?
Совсем наоборот.
Упс, у меня тег irony потерялся
Все статические анализаторы проверяют проекты и потом пишут про это. Собственно не понятно, что тут передирать. Идея не поверхности.

Хочу ещё заметить, что считаю свои статьи намного интереснее. В них есть что почитать. А тут сплошное бла-бла-бла…
Особенно рад за php, если честно, не ожидал…
И что мы будем делать с linux 2.6? Уже 3.4-rc5 на дворе…
и там весь старый код выкинули?
Нет, не весь. Но если они смотрели, например 2.6.32, то между ним и современными версиями проходит огромное количество изменений. cgroups, отказ от глобальных блокировок критических секций (== переписана куча драйверов), куча изменений в управлении памятью и т.д.

С точки зрения актуальности это исследование для 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
Это transition пакет, практически 100%. Новый virtual package называется linux-mage.
А без регистрации нельзя ознакомиться с отчетом?
«Серьезные» клиенты все равно до сих пор смотрят на Postgre как на НЁХ, им подавай Oracle или MSSQL на худой конец. Переубедить сложно.
> средний размер тестируемых проектов составлял 832 000 строк.
> число ошибок на тысячу строк кода, который составил в среднем 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
Ну как посмотреть.

В рамках треда на Хабре/ЛОРе/* достаточно заявить, что из того факта, что число ошибок растёт нелинейно при росте кода, не следует, что оно растёт именно как f(832000)=374, f(7500000)=4800. Возможно, у проприетарных программ f(832000)=457 (0.55 на тысячу строк кода, что всё равно даёт нелинейный рост).

С точки зрения же более-менее строгого обоснования из опубликованных данных вообще ни один из этих выводов сделать нельзя, поскольку это средняя температура по больнице, причём непонятно, какая выборка и какое именно среднее. Может, там один проект был, у которого на тысячу строк две сотни ошибок приходится, потому что язык выразительный и кодеры из Полинезии.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории