обоснование Misra 2012, не допускающего приведения между разными указателями

Я хотел бы вернуться к тому, что спросил ОП, и уточнить несколько вещей. Во-первых, нет проблем с вызовом void *memcpy(void *to, const void *from, size_t n), поскольку преобразование указателя на объект в указатель void не нарушает никаких рекомендаций MISRA-C:2012. Другими словами, любой инструмент, производящий нарушения для этого, просто глючит.

Во-вторых, прежде чем прийти к какому-либо выводу, важно прочитать, что на самом деле говорит Правило 11.5, соответствующее руководство MISRA-C:2012, а именно:

  Rule 11.5
  A conversion should not be performed from pointer to void into
  pointer to object

  Category Advisory
  Analysis Decidable, Single Translation Unit
  Applies to C90, C99

  Rationale
  Conversion of a pointer to void into a pointer to object may result
  in a pointer that is not correctly aligned, resulting in undefined
  behaviour. It should be avoided where possible but may be necessary,
  for example when dealing with memory allocation functions. If
  conversion from a pointer to object into a pointer to void is used,
  care should be taken to ensure that any pointers produced do not
  give rise to the undefined behaviour discussed under Rule 11.3.

Наблюдения:

1. это рекомендательное правило (т. е. не обязательное и не обязательное), поэтому от него можно отклоняться, и MISRA определил правильный процесс отклонения;
2. преобразование указателя на объект в указатель на void — это нормально, а наоборот проблематично;
3. в обосновании явно упоминаются функции выделения памяти (и да, программу, использующую динамическое выделение памяти, можно привести в соответствие с MISRA-C:2012);
4. обоснование дает руководство о том, что делать при преобразовании указателей на объекты в указатели на пустоту, что полностью соответствует тому, что хотел бы иметь OP («информация с просьбой дважды проверить упаковку, выравнивание и все остальное, что может пойти не так»).

Это не отвечает на ваш вопрос, который касается обоснований. Скорее, это указывает на то, что вы не должны быть в такой ситуации в первую очередь.

Ввод «misra malloc» в вашу любимую поисковую систему приводит нас к:

http://www.misra.org.uk/forum/viewtopic.php?t=260

который спрашивает:

Согласно правилу, мы не должны использовать такие функции, как malloc(), free(), calloc() и т. д. Но malloc() является очень распространенным требованием. Большинство встроенных системных приложений используют свои собственные диспетчеры памяти на уровне приложений, чтобы ускорить выделение и освобождение памяти. Есть ли у вас какие-либо предложения по решению этой проблемы (если мы не можем использовать malloc каким-либо другим способом)?

И ответ таков:

Нас спрашивали о решениях и обходных путях для различных вещей, которые запрещены как в MISRA C1, так и в MISRA C2, таких как использование malloc, calloc и т. д. для динамического выделения памяти. Ни MISRA, ни любой член рабочей группы MISRA C не будет давать никаких указаний или одобрений в отношении каких-либо отклонений или «обходных путей».

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

Например, вы упоминаете memcpy. Это не соответствует требованиям. Так что сделайте шаг назад и спросите: «Предположим, у меня нет никакой реализации memcpy. Как мне написать свою собственную memcpy, которая была бы совместима?» Вы используете memcpy для решения проблемы; решить проблему без него.

Теперь сделайте то же самое для malloc. Был день, когда malloc не существовало, и кто-то должен был написать его без malloc. У вас есть проблема, которую решает malloc. Если бы у вас не было malloc, как бы вы ее решили? В malloc нет ничего волшебного; вы можете написать свой собственный, который работает лучше, чем malloc, где под «лучше» я имею в виду «соответствует вашим требованиям».

MISRA-C:2012 на самом деле несколько слаб, когда дело доходит до преобразования указателей. Большинство правил разумны, они касаются того, чтобы заставить вас следовать стандарту C, не вызывать неопределенное поведение или делать универсально плохие вещи, такие как отбрасывание квалификаторов const из указателя. У вас не должно быть никаких возражений против всего этого.

Единственное спорное правило — 11.5:

Не следует выполнять преобразование из указателя на void в указатель на объект.

Я думаю, что это то, что вызывает у вас головную боль. Обоснованием являются проблемы выравнивания и преобразования между несовместимыми типами указателей, которые могут привести к неопределенному поведению.

Это правило действительно косвенно запрещает использование многих базовых библиотечных функций, таких как memcpy. Моя личная рекомендация MISRA относительно этого правила во время обзора 2012 года была следующей:

(Совершенно не согласен) «Существует слишком много случаев общего программирования на C, когда необходимы приведения типа void указателя. Это правило непрактично и принесет больше вреда, чем пользы. Вместо этого создайте правило, запрещающее конкретную опасность, от которой оно пытается защитить». , а именно "указатель-x, приведенный к void*, приведенный к указателю-y"."

Но они не послушались, и вот оно: бесполезное правило, которое заставляет каждый инструмент выдавать поток ложных срабатываний. Это означает, что каждый пользователь MISRA должен игнорировать это правило. Он носит рекомендательный характер, поэтому вы можете игнорировать его, не вызывая никаких процедур отклонения. Просто заблокируйте его в своем статическом анализаторе и двигайтесь дальше.

Комитету MISRA еще только предстоит осознать, что ложные срабатывания сами по себе представляют угрозу безопасности, поскольку они могут привести к тому, что люди начнут переписывать идеальный код и, таким образом, внесут ошибки.

как мисра ожидает malloc

MISRA ожидает, что вы вообще не будете использовать malloc, это явно запрещено директивой 4.12 по очень веским причинам. Но это другая тема.