Зачем нужны прототипы функций в MISRA:2012?

void display(void); — это предварительное объявление функции. Он имеет формат прототипа.

Как указано в размещенной ссылке, функция prototype представляет собой объявление функции с указанными типами всех параметров. Если параметров нет, то список параметров должен быть (void) (без параметров), а не () (любой параметр).

Точное правило 8.2 гласит:

Правило 8.2 Типы функций должны быть в форме прототипа с именованными параметрами.

В представленном обосновании (читай, оно довольно хорошее) упоминается, что это делается для того, чтобы избежать старых программ K&R и C90, в которых указаны не все параметры. C99 по-прежнему допускает это в некоторой степени, пока типы параметров в объявлении функции не конфликтуют с типами параметров в определении функции.

По сути, правило направлено на запрет таких функций:

void func1 (x)  // K&R style
int x;
{}

void func2(x)  // sloppy style
{}

Все параметры (если они есть) должны иметь указанные типы и имена.

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

Хотя, как я упоминал в предыдущем ответе, написание файлов .c без объявлений функций (в формате прототипа) является небрежной практикой. Если ваши функции должны вызываться в определенном порядке, это должно быть очевидно с помощью дизайна программы, именования функций и комментариев/документации. Не в том порядке, в котором они были объявлены внутри файла .c.

Не должно быть жесткой связи между строкой исходного кода, где функция объявлена ​​в файле .c, и поведением/использованием этой функции.

Вместо этого функции должны быть определены в порядке, который имеет логический смысл. Обычный способ написания файлов .c состоит в том, чтобы хранить все общедоступные функции, объявление функций которых находится в файле .h, в верхней части файла .c. Затем пусть внутренние функции (с static/внутренней связью) будут внизу. Эта модель требует объявления всех внутренних функций. Другой вариант — поместить все внутренние функции вверху, а общедоступные — внизу. Пока вы последовательны, любой из них в порядке.

Что наиболее важно, так это то, что если определения функций в файле .c переупорядочиваются, это не должно нарушать работу программы или вызывать ошибки компилятора. Самый простой способ обеспечить это — всегда предоставлять объявления функций для каждой отдельной функции в вашей программе.

Обратите внимание, что объявления функций в верхней части файла вовсе не «по-настоящему бесполезны», поскольку они предоставляют краткий обзор всех функций, присутствующих в файле C. Это способ написания самодокументируемого кода.

Обратите внимание, что стандарт C не допускает прототипа для main() в качестве особого случая.

Обратите внимание, что, кроме того, правила 8.7 и 8.8 запрещают вам использовать void display(void) без static, поскольку функция используется только в одной единице перевода.

Если вы не объявляете функцию, любой вызов функции будет вызывать default argument promotions для каждого аргумента, поскольку считается, что функция имеет семантику стандарта C89.

Case 1:

Рассмотрим вызов f(5), где параметр функции имеет тип double. Код f будет рассматривать 5 как двойное число, в то время как арифметические продвижения по умолчанию будут передавать только целое число.

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

Case 2:

Предположим, вы хотите использовать функцию strtok и не включаете заголовок string.h в объявление -- char *strtok(char *str, const char *delim)

Теперь вы делаете ошибку, рассматривая разделитель «А» вместо «А». Поэтому, если вы забудете подпись, но имейте в виду значение параметров, если вы не включите заголовок, код будет скомпилирован без предупреждения, и, конечно, код из strtok будет учитывать ваш char 'A' (который преобразуется в целое число (=95)) в качестве фактического аргумента. Код считает, что это указатель на строку, и попытается получить доступ к указателю с позиции 95, заканчивая segfault.

Case 3:

Вот еще один типичный пример кода, который дает сбой сегментации на некоторой архитектуре — даже если вы не делаете ошибок, он все равно дает сбой сегментации.

char *subtoken;
subtoken = strtok(str, delim, &saveptr);

В этом случае считается, что функция strtok (отсутствует объявление из string.h) возвращает int, поэтому выполняется неявное преобразование из int->char*. Если int представлен 32 битами, а указатель — 64 битами, очевидно, что значение subtoken будет ошибочным и приведет к ошибке seg.