Comments 10
Такая маленькая ошибка, а сломала всю вёрстку: браузер не сможет отобразить эту страницу.
Вы это, слона не натягивайте! Браузер спокойно такое пережовывает.
Вау... "Они выросли, и забыли, как это делается". Современные браузеры разучились автоматом чинить такой html O_O
Удивил фрагмент N4. В цикле делается раз за разом malloc
, результат сохраняется каждый раз в одну и ту же переменную... Это вы вырезали фрагменты, но не пометили многоточием?
Спасибо за вашу внимательность! Фрагмент кода поправила, теперь все корректно.
Так же проверила возможную утечку памяти, но она оказалась маловероятной, т.к. указатель чаще всего сохраняется и используется уже вне функции. Например, сохранение происходит в этом месте, а так же в этом месте при передачи в эту функцию. А очистка памяти происходит только в этом случае, когда не получилось добавить указатель.
Без ссылки на фидбек от разработчиков профессиональному обзору недостает профессиональной этики, имхо.
Спасибо, что поделились ссылкой в комментариях. Мы всегда создаем задачи на исправление, когда пишем про проверку проектов. А ответ от разработчиков появился уже после выпуска статьи, поэтому упомянуть его ранее не получилось.
Мы рады, что разработчики смогли дать нам такой подробный ответ. Но некоторых случаях мы не со всем согласны. Например, с тем, что не надо проверять, что вернула функция malloc
.
Я согласна с тем, что N3 оказалось-таки ложным срабатыванием. Я некорректно посчитала, что аллокатор возвращает указатель на объект структуры, поля которого не были занулёны. Подробнее изучив код аллокатора, я поняла, что это не так. Пусть это и не является ошибкой, но такой код вводит в заблуждение. Думаю, его можно сделать проще, например, явно указать повторно extends_ast
во второй проверке. Статью поправила соответственно.
Кроме того, в статье мы рассмотрели лишь малую часть отчета. Так, например, статический анализатор выдал еще несколько предупреждений V595, которые можно поправить.
Дополнительные срабатывания V595
V595 The 'generator->execute_data' pointer was utilized before it was verified against nullptr. Check lines: 810, 826. zend_generators.c 810
V595 The 'parent_ce' pointer was utilized before it was verified against nullptr. Check lines: 1810, 3905, 3906. zend_inheritance.c 3905
V595 The 'ce' pointer was utilized before it was verified against nullptr. Check lines: 94, 242, 247. zend_interfaces.c 242
V595 The 'generator->execute_data' pointer was utilized before it was verified against nullptr. Check lines: 'zend_observer.h:97', 'zend_observer.h:115', ..., 'zend_generators.c:824', 'zend_generators.c:826'. zend_observer.h 115
V595 The 'filename' pointer was utilized before it was verified against nullptr. Check lines: 'zend_string.h:218', 'zend_stream.c:79', 'fopen_wrappers.c:468', 'fopen_wrappers.c:470'. zend_stream.c 79
V595 The 'new_value' pointer was utilized before it was verified against nullptr. Check lines: 590, 597. main.c 590
V595 The 'new_break->class_name' pointer was utilized before it was verified against nullptr. Check lines: 592, 605. phpdbg_bp.c 592
Я бы к пятому фрагменту в пояснении добавил, что realloc в случаях, когда не удается "растянуть" память, хоть и возвращает NULL, но и не освобождает память от старого блока. То есть тут ещё и утечка памяти, указатель-то теряется.
Я на ровно такой ошибке погорел, когда брал примеры из репы курла по работе с ним.
P.S.: не успел на тот момент долистать до шестого фрагмента. Наверное лучше было бы объединить их в рамках статьи, все равно один и тот же код.
Что делать, если ваш слон думает, что он баг?