Запретить сообщение 9007 lint

Согласно правилу 13.5 MISRA правый операнд логического && или || оператор не должен содержать стойких побочных эффектов. Наш код проверен с помощью PC-Lint, сообщение 9007 (http://gimpel-online.com/MsgRef.html#9007).

У нас есть код вида

if((GET_SIGNAL1() < CONST_1) || (GET_SIGNAL2() == CONST_2) ) { dostuff(); }

GET_x — это макросы, получающие сигнал x с некоторой обработкой ошибок, что позже вызывает предполагаемые побочные эффекты. Дано отклонение правила к MISRA 13.5, теперь вопрос как подавить соответствующие сообщения.

Усилия до сих пор: поскольку это автоматически сгенерированный код, я не могу напрямую вставлять комментарии lint, но вставлять комментарии через генератор, хотя и, в первую очередь, трудно отследить.

--e{(9007))} в определении макроса будет работать, но у нас также есть такой код, как foo = GET_SIGNAL1();, который вызовет деактивацию всей функции.

Про -ecall тоже думал, но он просто проверяет сам вызов, а не контекст макроса (как я надеялся).

редактировать:

Я не могу повлиять ни на модель, ни на тулчейн. Единственные части, на которые я могу повлиять, - это конфигурация ворса или «связующий код», например определения макросов.


c misra pc-lint
person Lord_Gestalter    schedule 21.08.2014    source источник
comment
Могу я спросить, почему вы используете lint для сгенерированных файлов? Как правило, он предназначен для того, чтобы избежать распространенных проблем при написании от руки c, сгенерированный c должен быть правильным и не обязательно должен быть таким четким.   -  person Vality    schedule 21.08.2014
comment
Не уверен, какую магию вы ожидаете здесь, вы закрыли все возможности для очевидного обходного пути. Самый простой способ — перестать нарушать правило. Может быть таким же простым, как использование | вместо ||. Лучше всего изолировать этот код в отдельной TU, чтобы вы могли применить глобальное переопределение.   -  person Hans Passant    schedule 21.08.2014
comment
@HansPassant Разве это не изменит поведение, я думаю, что это основано на коротком замыкании, так что GET_SIGNAL2 можно запустить только в том случае, если GET_SIGNAL1   -  person Vality    schedule 21.08.2014
comment
@Vality MISRA также применяется к автоматически сгенерированному коду. Единственным отличием является классификация правил на обязательные, обязательные и рекомендательные изменения.   -  person Lord_Gestalter    schedule 21.08.2014
comment
@HansPassant Но это было бы побитовое сравнение, а не принудительное выполнение второй стороны. Думаю, я знаю, что ты имеешь в виду, но это был другой язык.   -  person Lord_Gestalter    schedule 21.08.2014
comment
@Vality В противном случае Приложение E, Применимость к автоматически сгенерированному коду не имело бы особого смысла.   -  person Lord_Gestalter    schedule 21.08.2014

Ответы (2)


arrow_upward
1
arrow_downward

Можете ли вы изменить генератор для вывода нового макроса, например:

#define TEST_SIGNALS(a,b,c,d)   ((a<b) || (c<d))

if (TEST_SIGNALS(GET_SIGNAL1(), CONST_1, GET_SIGNAL2(), CONST_2))
{
   dostuff()
}

И отключите предупреждение следующим образом:

//lint -emacro(9007, TEST_SIGNALS)
person snowcrash09    schedule 21.08.2014
comment
Хорошая идея, но я не могу повлиять ни на модель, ни на цепочку инструментов, включая генератор. - person Lord_Gestalter; 21.08.2014

arrow_upward
0
arrow_downward

Мы намерены решить проблему, описанную выше, с помощью двух запусков Lint:

  • 1-й запуск с продуктивным кодом и глобально деактивированным сообщением 9007
  • Второй запуск с заглушенным макросом без предполагаемого побочного эффекта, но не активировано ничего, кроме сообщения 9007.
person Lord_Gestalter    schedule 03.09.2014
comment
Не приму это как ответ, просто для вдохновения, если у вас есть аналогичная проблема. - person Lord_Gestalter; 03.09.2014