Комментарии 35
Причины некоторых багов стали мне вдруг ясны.
Полезная статья, даже не задумывался, что можно сам PHP на баги проверить.
Интересно количество багов в сравнении с конкурентами.
Не ожидал что так мало полезных сообщений будет, учитывая сколько багав в багтрекере.
Было бы интересно сравнить например с HipHop PHP, как в Фейсбуке дила с качаством.
Было бы интересно сравнить например с HipHop PHP, как в Фейсбуке дила с качаством.
Очень часто баги, это не «очепятки» в коде, когда два раза пишется одно и то же условие и т.п., а абсолютно верная с точки зрения синтаксиса языка и логики конструкция, но в итоге выполняющая не то, что надо. И анализатор тут не поможет совершенно, ведь все же правильно и логично. Простейший пример, программа должна находить разность, а в коде сумма. Но анализатору-то неизвестно, что тут должно быть, с его точки зрения все будет совершенно правильным. Ну разве что переменные беззнаковые, где-то дальше проверка на неотрицательность результата и он скажет, что в ней нет смысла. Но это еще постараться надо.
тоесть вы говорите что написание тестов гарантировано лучше статического анализа, так как кроме багов еще и опичатки отлавливает?
Я попрошу вас не додумывать за меня мои мысли, я такого не говорил ни разу и это никоим образом не следует из моего комментария. Я лишь указал на то, что нет прямой связи между кол-вом заявок в багтрекере и ошибок в коде, найденных анализатором, и попытался объяснить причину этого. Каждый метод поиска ошибок для своего. Для того, чтобы найти где «очепятка» проще постоянно использовать статический анализатор, а для проверки правильности тесты и живое использование с багтрекером. К слову, тест может и не отловить опечатку, если он не покрывает то место, в котором она расположена, так что вы дважды неправы, тесты не лучше анализатора (как я уже говорил, каждому свое) да еще и делаете какие-то свои, непонятные выводы из чужих слов, додумывая их «скрытый смысл» без участия автора.
Удивительно мало багов, причём в extensions (хоть и включенных в поставку), а не в ядре.
Я приведу всего несколько примеров из некоторых библиотек, дабы следовать тематике статьи и просто поднять вопрос о доверии к сторонним библиотекам.
Много подозрительных мест есть в libiconv, zend и других, особенно много в pcrelib. Разработчикам, знакомым с кодом, явно будет что посмотреть в полном отчёте проверки.
То что вы привели выше этого раздела тоже не является ядром PHP.
SAPI / ftp / crypt это встроенные extensions.
SAPI / ftp / crypt это встроенные extensions.
Немного запоздало, но все же, раз уж речь пошла о расширениях php, можно ли попросить вас проверить PHP-CPP?
В случае PDO указатель не разыменовывается. Просто прибавляется смещение.
Это ничего не значит. Как Вам такой поворот событий "Новые оптимизации с использованием неопределенного поведения в gcc 4.9.0"? Подумайте о глубине глубин.
А проверьте, пожалуйста, cppcms!
Может я невнимателен, но я не понял какую версию PHP проверяли.
Ответы на вопросы читателей статей про PVS-Studio и CppCat, версия 2014: Какую версию этого проекта вы проверяли? Trunk (или stable)? Так надо stable (или trunk)!.
Спасибо за труд. Надеюсь, это пойдёт на пользу любимому языку, который в последнее время быстро развивается и радует своими новшествами.
По моему, разрабы PHP имели лицензию на PVS-Studio, даже в их репе видел ветки где фиксили 64битные замечания. Так что не удивительно что баги в основном в сторонних либах.
P.S. Мне ваш коммент напомнил одну старую шутку про PHP:
У нас было два Оптерона, 16 гигабайт оперативки, 2 гига под мемкеш, полвинчестера свободно и целое множество плагинов и модулей всех сортов и расцветок, а также Апач, MySQL и гигабайт чистого свопа. Не то чтобы это был необходимый набор для Друпала, но если начал писать на PHP, становится трудно остановиться. Единственное, что вызывало у меня опасение — это своп. Нет ничего более беспомощного, безответственного и испорченного, чем свопящийся сервер. Я знал, что рано или поздно мы перейдем и на эту дрянь.
P.S. Мне ваш коммент напомнил одну старую шутку про PHP:
У нас было два Оптерона, 16 гигабайт оперативки, 2 гига под мемкеш, полвинчестера свободно и целое множество плагинов и модулей всех сортов и расцветок, а также Апач, MySQL и гигабайт чистого свопа. Не то чтобы это был необходимый набор для Друпала, но если начал писать на PHP, становится трудно остановиться. Единственное, что вызывало у меня опасение — это своп. Нет ничего более беспомощного, безответственного и испорченного, чем свопящийся сервер. Я знал, что рано или поздно мы перейдем и на эту дрянь.
Как насчет того чтобы стабильную или HEAD ветку ruby проверить?
Уже по sqlite-dev рассылке письмецо пришло только что:
Проверил свежий сегодняшний снапшот, все так же — sizeof(p).
Пробежавшись поиском по sqlite.c, вроде, нашел еще одно место:
В общем, дальше по коду внутри функции(sqlite3_result_blob) вызывается:
Похоже на баг, жду ответов в подписке.
Greeting.
On
> www.viva64.com/en/b/0277/
there is a static analysis of the PHP interpreter. So far, so good.
What makes this of potential interest for the SQLite developers is the
following excerpt:
«Third-party libraries do make a large contribution to project
development allowing one to reuse already implemented algorithms, but
their quality should be checked as carefully as that of the basic
project code. I will cite just a few examples from third-party
libraries to meet the article's topic and simply muse over the
question of our trust in third-party libraries.
The PHP interpreter employs plenty of libraries, some of them slightly
customized by the authors for their needs.
libsqlite
V579 The sqlite3_result_blob function receives the pointer and its
size as arguments. It is possibly a mistake. Inspect the third
argument. sqlite3.c 82631
static void statInit(....)
{
Stat4Accum *p;
…
sqlite3_result_blob(context, p, sizeof(p), stat4Destructor);
…
}
I guess the programmer wanted to get the size of the object, not the
pointer. So it should have been sizeof(*p).»
Is this a
a) a bug in SQLite that
a1) has been fixed for a long time,
a2) is still open,
b) not a bug in SQLite (thus a fallacy by the author of the article)?
Проверил свежий сегодняшний снапшот, все так же — sizeof(p).
Пробежавшись поиском по sqlite.c, вроде, нашел еще одно место:
static int fts3ColumnMethod(
sqlite3_vtab_cursor *pCursor, /* Cursor to retrieve value from */
sqlite3_context *pCtx, /* Context for sqlite3_result_xxx() calls */
int iCol /* Index of column to read value from */
){
int rc = SQLITE_OK; /* Return Code */
Fts3Cursor *pCsr = (Fts3Cursor *) pCursor;
Fts3Table *p = (Fts3Table *)pCursor->pVtab;
...
/* The extra column whose name is the same as the table.
** Return a blob which is a pointer to the cursor. */
sqlite3_result_blob(pCtx, &pCsr, sizeof(pCsr), SQLITE_TRANSIENT);
...
}
В общем, дальше по коду внутри функции(sqlite3_result_blob) вызывается:
SQLITE_PRIVATE int sqlite3VdbeMemSetStr(
Mem *pMem, /* Memory cell to set to string value */
const char *z, /* String pointer */
int n, /* Bytes in string, or negative */
u8 enc, /* Encoding of z. 0 for BLOBs */
void (*xDel)(void*) /* Destructor function */
){ }
Похоже на баг, жду ответов в подписке.
А вот и ответ. Как оказывается, все немного сложнее:
I doubt this is an error at all. While it is true that the sqlite3_result_blob function uses a pointer to storage and the length of that storage are to determine the size of the blob, this information is only really necessary if the entire blob needs to be copied somewhere, as for example, if the destructor were SQLITE_TRANSIENT or if the blob were to be copied directly to a record.
When the blob value is accessed (with sqlite3_value_blob), the pointer returned will be the pointer to the original memory structure. Since that pointer is then cast back to the pointer type of the original structure (Stat4Accum*) there is no need for the length (size of the blob) to be accurate — the size and extent information is encoded right in the structure itself.
This may simply optimize internal processing within the various value/result routines. Since the value returned has its own destructor, sqlite knows when the pointer is no longer valid, and the destructor will clear and release the whole allocated memory.
Очень интересно. Думаю, что не менее интересно будет про SpiderMonkey и v8.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заметка про проверку PHP