Выполните один или несколько из следующих шагов до тех пор, пока вы не определите исправление для проверки Unreachable code. Существует несколько способов исправить эту проверку. Для получения описания примеров проверки и кода смотрите Unreachable code.
Если вы определяете, что чек представляет защитный код, добавьте комментарий и обоснование в свой результат или код, объясняющие, почему вы не изменили код. Смотрите Адрес Результаты Polyspace через исправления ошибок или обоснования.
Выберите проверку на Results List или Source панели.
Просмотрите сообщение на панели Result Details.
Сообщение объясняет, почему блок кода недоступен.
Блок кода обычно недоступен, когда не удовлетворено условие, которое определяет вход в блок. Посмотрите, почему условие не удовлетворено.
На панели Source поместите курсор на переменные, вовлеченные в условие, чтобы определить их значения.
Используя эти значения, посмотрите, почему условие не удовлетворено.
Примечание
Иногда само условие избыточно. Для примера это всегда верно или связано:
Через || оператор другому условию, которое всегда соответствует true.
Через && оператор другому условию, которое всегда ложно.
Для примера в следующем коде условие x%2==0 является избыточным, потому что первое условие x>0 всегда верно.
assert(x>0); if(x>0 || x%2 == 0)
Проследите поток данных для каждой переменной, участвующей в условии.
В следующем примере проследите поток данных для arg.
void foo(void) {
int x=0;
.
.
bar(x);
.
.
}
void bar(int arg) {
if(arg==0) {
/*Block 1*/
}
else {
/*Block 2*/
}
}bar вызывается только из foo. Поскольку единственный аргумент bar имеет значение 0, else ветвь if(arg==0) недоступен.Возможное исправление: Если вы не собираетесь звонить bar в другом месте и знать, что значения перешли к bar не изменится, можно удалить if-else оператор в bar и сохранять только содержимое Block 1.
Чтобы проследить поток данных, выберите проверку и отметьте информацию на панели Result Details.
Если на панели Result Details отображается последовательность команд, ведущих к проверке, выберите каждую инструкцию.
Если на панели Result Details отображается номер линии вероятной причины проверки, щелкните правой кнопкой мыши на панели Source. Выберите Go To Line.
В противном случае для каждой переменной, участвующей в условии, найдите предыдущие образцы и вернитесь к первопричине проверки. Для получения дополнительной информации об общих первопричинах смотрите Шаг 3: Проверьте общие причины проверки.
В зависимости от переменной используйте следующие навигационные ярлыки для поиска предыдущих образцов. В Polyspace можно выполнить следующие шаги® только пользовательский интерфейс.
| Переменная | Как найти предыдущие образцы переменной |
|---|---|
Локальная переменная | Используйте один из следующих методов:
|
Глобальная переменная Щелкните правой кнопкой мыши переменную. Если появляется Show In Variable Access View опция, переменная является глобальной переменной. |
|
Функция возврата значение
ret=func(); |
|
Можно также определить, связаны ли переменные в любой операции с какой-либо предыдущей операцией. См. Раздел «Поиск отношений между переменными в коде».
Проверьте общие причины проверки Unreachable code.
Проверьте следующее в своем if тесты:
Вы проверяете переменные, которые вы собираетесь протестировать.
Например, у вас может быть локальная переменная, которая затеняет глобальную переменную. Возможно, вы тестируете локальную переменную, когда хотите протестировать глобальную.
Вы используете круглые скобки, чтобы навязать последовательность, в которой вы хотите операции в if тест для выполнения.
Для примера, if((!a && b) || c) налагает отличную последовательность операций от if(!(a && b) || c). Если вы не используете круглые скобки, операции подчиняются правилам приоритета операторов. Правила могут привести к выполнению операций в последовательности, которую вы не планировали.
Вы используете = и == операторы в нужные области кадра.
Возможное исправление: Исправление ошибок, если таковые имеются.
Используйте Polyspace Bug Finder™, чтобы проверить на общие дефекты, такие как Invalid use of = operator и Variable shadowing.
Чтобы избежать ошибок из-за неправильной последовательности операций, проверяйте на нарушения MISRA C:2012 Rule 12.1.
Проверьте, выполняете ли вы тест, который вы выполнили ранее.
Избыточный тест обычно происходит от аргумента функции. Один и тот же тест выполняется как в вызов, так и в функции called.
void foo(void) {
if(x>0)
bar(x);
.
.
}
void bar(int arg) {
if(arg==0) {
}
}Возможное исправление: Если вы хотите позвонить bar позже, например, в еще неписанном коде или повторно используйте bar в других программах сохраните тест в bar. В противном случае удалите тест.
Посмотрите, недоступен ли ваш код, потому что он следует break или return оператор.
Возможное исправление: Посмотрите, поместили ли вы break или return оператор в непреднамеренном месте.
Проверьте, существует ли раздел недоступного кода, поскольку вы следуете стандарту кодирования. Если это так, сохраните раздел.
Для примера, default блок switch-case оператор присутствует, чтобы захватить ненормальные значения switch переменная. Если такие значения не происходят, блок недоступен. Однако вы можете нарушить стандарт кодирования, если удалите блок.
Проверьте, связан ли недостижимый код с оранжевой проверкой ранее в коде. После оранжевой проверки Polyspace обычно завершает пути выполнения, которые содержат ошибку. Из-за этого отключения код, следующий за оранжевым чеком, может оказаться серым.
Например, Polyspace помещает оранжевую проверку на dereference указателя мыши ptr если вы не проверили ptr для NULL. Однако после дереференции он считает, что ptr не NULL. Если тестовое if(ptr==NULL) следует дереференции ptrPolyspace помечает соответствующий кодовый блок недоступным.
Для получения дополнительных примеров смотрите:
Серый чек после оранжевого чека
Исключение из этого поведения - переполнение. Если вы задаете соответствующий Overflow mode for signed integer или Overflow mode for unsigned integer, Polyspace переносит результат переполнения и не завершает пути выполнения. См. Overflow mode for signed integer (-signed-integer-overflows) или Overflow mode for unsigned integer (-unsigned-integer-overflows).
Возможное исправление: Исследуйте оранжевую проверку. В приведенном выше примере исследуйте, почему тест if(ptr==NULL) происходит после дереференции, а не до.