Функциональный макрос REPORT_ERROR, определенный [Директива MISRA 2012 4.9, рекомендательный]

Я определил MACRO, который будет вызывать функцию и передавать аргумент. Получение ниже предупреждения MISRA для этого случая. Разве это не разрешено? Как этого избежать?

Каковы преимущества вызова функции (функций) в MACRO, как показано ниже?

#define REPORT_ERROR(Id, Error) ReportErr((uint16)21, (uint8)0, (uint8)Id, (uint8)Error)

void ReportErr(uint16 ModuleId, uint8 InstanceId, uint8 ApiId, uint8 ErrorId)
{

  // function - body

}

c lint misra
person kapilddit    schedule 24.09.2019    source источник
comment
Создать (встроенную) функцию REPORT_ERROR, которая вызывает функцию ReportError?   -  person Some programmer dude    schedule 24.09.2019
comment
Вы можете избежать макроса, используя другую (встроенную) функцию, например void ReportErr_21_0(uint8 ApiId, uint8 ErrorId) { ReportErr((uint16)21, (uint8)0, ApiId, ErrorID); }   -  person Weather Vane    schedule 24.09.2019
comment
И помните, что MISRA очень строга и запрещает многие вещи, которые часто являются законными и действительными. Если у вас нет строгих требований к проверке соответствия требованиям MISRA, я настоятельно не рекомендую это делать.   -  person Some programmer dude    schedule 24.09.2019
comment
@Someprogrammerdude Или, в качестве альтернативы, можно было бы изучить MISRA, прежде чем использовать его. Правила имеют различную степень строгости и рекомендательного характера. Можно отступить от таких правил, не используя формальную процедуру отклонения. Однако рекомендательные правила должны быть учтены в стандарте кодирования компании. Многие из них очень здравые.   -  person Lundin    schedule 24.09.2019

Ответы (1)


arrow_upward
4
arrow_downward

Некоторые из правил MISRA-C носят «очень рекомендательный характер» до такой степени, что вы не можете им соответствовать и, возможно, захотите выдвинуть против них постоянное отклонение. Прекрасным примером этого является правило против использования макросов, подобных функциям.

Каждый программист на C знает, что макросы, подобные функциям, плохи по многим веским причинам. Но часто их просто невозможно обойти. Таким образом, важность правила состоит в том, чтобы подтолкнуть к тому, чтобы макросы, подобные функциям, были последним средством, если программист каким-то образом не знал об этом. Практического применения правила нет.

В этом конкретном случае кажется, что макрос предназначен только для компенсации плохого API или плохого кода вызывающей стороны. Есть много альтернативных способов решить эту проблему:

  • Сделайте некоторые параметры функции необязательными, позволив вызывающей стороне передать NULL или что-то подобное.
  • Используйте какой-то набор аргументов по умолчанию в вызывающем объекте и выбирайте там аргументы в зависимости от варианта использования.
  • Ни в одном из вышеперечисленных вариантов нет, используйте отдельную функцию или встроенную функцию-оболочку.

Другие вещи:

MISRA или нет MISRA, в вашем коде не должно быть «магических чисел». Магического числа 21 не должно быть ни с того ни с сего, его нужно заменить константой.

Кроме того, вы должны использовать stdint.h вместо использования собственного гаражного стандарта для целочисленных типов. Если вы застряли на C90, используйте определения типов в пользовательском заголовке, соответствующем тем, что в stdint.h.

person Lundin    schedule 24.09.2019