Спасибо, что поделились ссылкой в комментариях. Мы всегда создаем задачи на исправление, когда пишем про проверку проектов. А ответ от разработчиков появился уже после выпуска статьи, поэтому упомянуть его ранее не получилось.
Мы рады, что разработчики смогли дать нам такой подробный ответ. Но некоторых случаях мы не со всем согласны. Например, с тем, что не надо проверять, что вернула функция 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
Спасибо за вашу внимательность! Фрагмент кода поправила, теперь все корректно.
Так же проверила возможную утечку памяти, но она оказалась маловероятной, т.к. указатель чаще всего сохраняется и используется уже вне функции. Например, сохранение происходит в этом месте, а так же в этом месте при передачи в эту функцию. А очистка памяти происходит только в этом случае, когда не получилось добавить указатель.
На данный момент мы следим за развитием стандартов C++ и ждем окончательного утверждения механизмов рефлексии, чтобы после рассмотреть возможность внедрения. Сейчас мы планируем расширение покрытия правил MISRA C и улучшение нового ядра анализатора
Да, стандарт гарантирует, что элементы массива лежат последовательно, так же, как и гарантирует неопределенное поведение при выходе за границы массива.
Нет, в данный момент в C# анализаторе нет диагностического правила, которое выявляло бы возможные проблемы из-за изменения в поведении. При быстром взгляде, кажется, что это хорошая диагностика для группы Customers' Specific. Мы рассмотрим эту идею подробнее для оценивания возможности добавления в группу General. Вы можете написать нам в поддержку, чтобы мы могли общаться с вами напрямую.
В обоих указанных вами случаях срабатывание будет выдано верно, потому что сама диагностика на это и рассчитана:
Анализатор заметил в коде следующую ситуацию. В начале, указатель используется. А уже затем этот указатель проверяется на значение NULL. Это может означать одно из двух:
Возникнет ошибка, если указатель будет равен NULL.
Программа всегда работает корректно, так как указатель всегда не равен NULL. Проверка является лишней.
Если говорить про варианты, которые указаны в цитате, то для решения проблемы в первом варианте нужно пересмотреть место срабатывания на наличие неправильного расположения проверки и/или использования, а во втором варианте просто убрать лишнюю проверку
Данная диагностика не направлена на отслеживание валидности указателя. Анализатор выдает предупреждение на случаи, когда указатель используется, а после проверяется. Возможно, так же поможет разобраться в вопросе документация и отдельная статья "Пояснение про диагностику V595".
Я немного не понимаю ваш вопрос, но могу попытаться дать ответ на него. Если мой ответ не помог, то попробуйте задать свой вопрос по-другому
Предупреждение было выдано на разыменование указателя xdriver, который после использования проверяется на валидность. Здесь анализатор PVS-Studio верно сработал. В самой статье приведено три варианта исправления найденной проблемы:
С сохранением замысла исходного кода. В таком варианте происходит замена static_cast на dynamic_cast и перемещение проверки валидности указателя в место до его разыменования.
С изменением архитектуры классов. В таком варианте интерфейс Shutdown вынесен в базовый класс в виде чистой виртуальной функции, а AudioSystem::DestroyDriver сделан невиртуальным.
Использование 2 варианта с идиомой NVI.
Если воспользоваться одним из вариантов, то проблемы уже не будет, и PVS-Studio не будет выдавать предупреждение.
Спасибо, что поделились ссылкой в комментариях. Мы всегда создаем задачи на исправление, когда пишем про проверку проектов. А ответ от разработчиков появился уже после выпуска статьи, поэтому упомянуть его ранее не получилось.
Мы рады, что разработчики смогли дать нам такой подробный ответ. Но некоторых случаях мы не со всем согласны. Например, с тем, что не надо проверять, что вернула функция
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
Спасибо за вашу внимательность! Фрагмент кода поправила, теперь все корректно.
Так же проверила возможную утечку памяти, но она оказалась маловероятной, т.к. указатель чаще всего сохраняется и используется уже вне функции. Например, сохранение происходит в этом месте, а так же в этом месте при передачи в эту функцию. А очистка памяти происходит только в этом случае, когда не получилось добавить указатель.
Проверяла на онлайн компиляторе. Работу кода с ошибкой можно посмотреть по ссылке. А исправленную по этой ссылке
На данный момент мы следим за развитием стандартов C++ и ждем окончательного утверждения механизмов рефлексии, чтобы после рассмотреть возможность внедрения. Сейчас мы планируем расширение покрытия правил MISRA C и улучшение нового ядра анализатора
Да, стандарт гарантирует, что элементы массива лежат последовательно, так же, как и гарантирует неопределенное поведение при выходе за границы массива.
Только что опубликовали вторую часть статьи про проверку PPSSPP. Приглашаю к прочтению)
Нет, в данный момент в C# анализаторе нет диагностического правила, которое выявляло бы возможные проблемы из-за изменения в поведении. При быстром взгляде, кажется, что это хорошая диагностика для группы Customers' Specific. Мы рассмотрим эту идею подробнее для оценивания возможности добавления в группу General. Вы можете написать нам в поддержку, чтобы мы могли общаться с вами напрямую.
Такое диагностическое правило так же есть в анализаторе PVS-Studio.
Да, все верно
В обоих указанных вами случаях срабатывание будет выдано верно, потому что сама диагностика на это и рассчитана:
Если говорить про варианты, которые указаны в цитате, то для решения проблемы в первом варианте нужно пересмотреть место срабатывания на наличие неправильного расположения проверки и/или использования, а во втором варианте просто убрать лишнюю проверку
Данная диагностика не направлена на отслеживание валидности указателя. Анализатор выдает предупреждение на случаи, когда указатель используется, а после проверяется.
Возможно, так же поможет разобраться в вопросе документация и отдельная статья "Пояснение про диагностику V595".
Я немного не понимаю ваш вопрос, но могу попытаться дать ответ на него. Если мой ответ не помог, то попробуйте задать свой вопрос по-другому
Предупреждение было выдано на разыменование указателя xdriver, который после использования проверяется на валидность. Здесь анализатор PVS-Studio верно сработал.
В самой статье приведено три варианта исправления найденной проблемы:
С сохранением замысла исходного кода. В таком варианте происходит замена static_cast на dynamic_cast и перемещение проверки валидности указателя в место до его разыменования.
С изменением архитектуры классов. В таком варианте интерфейс Shutdown вынесен в базовый класс в виде чистой виртуальной функции, а AudioSystem::DestroyDriver сделан невиртуальным.
Использование 2 варианта с идиомой NVI.
Если воспользоваться одним из вариантов, то проблемы уже не будет, и PVS-Studio не будет выдавать предупреждение.