Как мне сказать gcov игнорировать нечитаемые строки кода C ++?
Я использую gcov для измерения покрытия в моем Код на C ++. Я хотел бы получить 100% охват, но мне мешает тот факт, что есть некоторые строки кода, которые теоретически недоступны (методы, которые необходимо реализовать, но которые никогда не называются, ветви по умолчанию switch операторов, так далее.). Каждая из этих веток содержит оператор assert (false); , но gcov по-прежнему помечает их как не пораженные.
Я бы хотел сказать gcov игнорировать эти ветви. Есть ли способ дать gcov эту информацию - с помощью аннотирования исходного кода или с помощью любого другого механизма?
2 ответа
Не могли бы вы представить модульные тесты соответствующих функций, которые существуют исключительно для остановки gcov путем прямой атаки на теоретически неуязвимые пути кода? Поскольку это модульные тесты, они, возможно, могли бы игнорировать «невозможность» ситуаций. Они могут вызывать функции, которые никогда не вызываются, передавать недопустимые значения перечисления для перехвата веток по умолчанию и т. Д.
Затем либо запускать эти тесты только для версии вашего кода, скомпилированной с помощью NDEBUG, либо запускать их в проводке, которая проверяет, что запускается assert - все, что поддерживает ваша тестовая среда.
Мне кажется немного странным, что в спецификации сказано, что должен быть код, а не в спецификации, содержащей функциональные требования к коду. В частности, это означает, что ваши тесты не проверяют эти требования, что является такой же хорошей причиной, как и любая другая, для сохранения функциональности требований. Лично я бы хотел изменить спецификацию, чтобы сказать: «если вызывается с недопустимым значением перечисления, функция не сможет выполнить assert . Вызывающие не должны вызывать функцию с недопустимым значением перечисления в режиме выпуска». Или что-то в этом роде.
Предположительно то, что он в настоящее время говорит, похоже на «все операторы switch должны иметь регистр по умолчанию». Но это означает, что стандарты кодирования мешают наблюдаемому поведению (по крайней мере, наблюдаемому в gcov), вводя мертвый код.Стандарты кодирования не должны этого делать, поэтому функциональная спецификация должна по возможности учитывать стандарты кодирования.
Если это не удастся, вы могли бы обернуть неоткрываемый код в #if! GCOV_BUILD и сделать отдельную сборку для удобства gcov. Эта сборка не соответствует некоторым требованиям, но при условии правильного анализа кода она дает вам уверенность в том, что набор тестов проверяет все остальное.
Изменить: вы говорите, что используете хитроумный генератор кода, но вы также запрашиваете решение, аннотируя исходный код. Если вы меняете источник, можете ли вы просто удалить мертвый код во многих случаях? Не то чтобы смена сгенерированного источника идеальна, но необходимо ...
Я не верю, что это возможно. Gcov зависит от gcc для генерации дополнительного кода для создания вывода покрытия. Сам GCov просто анализирует данные. Это означает, что Gcov не может анализировать код лучше, чем gcc (и я предполагаю, что вы используете -Wall и удалили код, указанный как недостижимый).
Помните, что перемещаемые функции могут быть вызваны откуда угодно, потенциально даже из внешних DLL или исполняемых файлов, поэтому компилятор никак не может знать, какие перемещаемые функции не будут вызываться или какие входные данные могут быть у этих функций.
Возможно, вам понадобится какой-нибудь удобный инструмент статического анализа, чтобы получить нужную информацию.