Valgrind — это хорошо, но недостаточно

[DISaccount]

«Fill(m_letters, m_letters + sizeof(m_letters)/sizeof(*m_letters), 0);»
А какой нибудь анализатор в итоге выловил выход за границу массива, если бы он задавался статически?
Вообще, как по мне, то пример несколько надуманный. Если уж и задавался массив статически, то программист вместо sizeof(m_letters)/sizeof(*m_letters) написал бы, скорее всего MAX_COUNT. Хотя и тот и тот варианты ведут к выходу за границу массива.

А в целом, согласен с утверждением, что «Надеюсь нам удалось показать отличия между статическим и динамическим анализатором кода. Эти два подхода хорошо дополняют друг друга.»

[Andrey2008]

По поводу выловит ли выход за границу массива какой-то анализатор. Динамический выявит почти наверняка. Статический — может выловит, может нет. Зависит от того, как задано количество обрабатываемых байт (если оно из файла читается, то тут никак… :). Например, вот здесь есть примеры, когда анализатор PVS-Studio обнаруживает выход за границу массива (хотя в основном там случаи, когда обрабатывается только часть массива).

Вообще, как по мне, то пример несколько надуманный.

Не понимаю. Что значит надуманный? Ошибка взята из кода маленького проекта, который прислал потенциальный клиент, чтобы мы там что-то попробовали найти.

[DmitryMe]

В вашем варианте предполагается вызов функции?

[DmitryMe]

Исходный вариант не предполагает вызова функции, поэтому его можно использовать внутри static_assert (и его аналогов для компиляторов, которые не поддерживают static_assert) и как число элементов массива фиксированного размера. Предлагаемый вами вариант так использовать нельзя.

[Andrey2008]

В Debug-режиме будет лишний вызов функции.

[Andrey2008]

Тем не менее, вариант из Chromium лучше. Здесь не место красоте :). Один раз написали и забыли.

[xeioex]

До сих пор еще ктото пользуется Valgrind? это практически неюзабельный софт для больших и сложных проектов. А в проектах с реалтаймовыми требованиями — совершенно не применим. Несколько лет уже используем clang.llvm.org/docs/AddressSanitizer.html, деградация производительности всего 2-3 раза что вполне приемлимо и не сопоставимо с 50-100 для valgrind.

[Sannis]

Вас не смущает что ASAN не всегда находит не освобожденную в конце программы память? А LSAN ещё считается экспериментальным.

[timurrrr]

Что самое обидное — что на больших и сложных проектах Valgrind работает ещё хуже, чем на маленьких и простых :-\

+1 к ASan'у.

[xeioex]

> ASAN не всегда находит не освобожденную в конце программы память?
ASAN не ищет утекшую память, а все возможные нарушения доступа к памяти. он так же с успехом применяется во в крупных проектах типа Chromium с 2011 года.

>А LSAN ещё считается экспериментальным.
Это же отладочный инструмент, если он с успехом помогает вам искать баги и утечки то какая разница эксперементальный он или нет. LSAN пользуемся чуть меньше года и пока опыт только положительный.

В своем проекте делаем несколько ежедневных сборок одна из них отладочная (с внедренным address-sanitizer), эта сборка прогоняется через те же автотесты что и основная сборка. Все это позволяет быстро и без особых усилий выявлять появляющиеся проблемы.

[mmatrosov]

Здесь: www.viva64.com/ru/b/0158/ у графика подпишите оси. Порадуйте математиков.

[Andrey2008]

Порадовал.
Пользуясь случаем, передаю всем привет. Плюс прошу читателей запостить в твиттер ссылку на описание C++ Quiz.

[mmatrosov]

Оппа, так это плотность. Это сразу менят восприятие. Я сначала думал, что это количество ошибок. Ещё удивился, что растёт вполне себе линейно.

Если позволите ещё немного позанудствовать, то теперь не указано, в чём измеряется плотность. Да, в таблице выше указано, что в кол-ве на 1000 строк кода. Но на графике единиц измерения нет. Первая мысль была про проценты. Радовала максимальная плотность в 100% :)

[Andrey2008]

Лучшее, враг хорошему. Позволю себе на этом остановиться. :) А так да, с замечанием согласен.

[Andrey2008]

Ради интереса проверил сам Valgrind: Проверяем код динамического анализатора Valgrind с помощью статического анализатора.