Следует ли размещать спецификатор класса хранения параметров в определении функции или в объявлении и определении?

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

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

Более того, в C89 прямо говорится

Спецификатор класса хранения в спецификаторах объявления для объявления параметра, если он присутствует, игнорируется, если объявленный параметр не является одним из членов списка типов параметра для определения функции.

(курсив добавлен). Определение функции - это объявление, сопровождаемое телом функции, в отличие от прямого объявления, поэтому ваши два кода имеют идентичную семантику.

С объявлением конкретного класса хранилища регистров и без него код компилируется правильно (я пробовал gcc, VC ++ и Watcom), я не смог найти никакой информации в стандарте ISO / ANSI C89 о том, что делать правильно, или все в порядке если я просто добавлю ключевое слово register в определение функции?

Лично я был бы склонен сделать каждое предварительное объявление идентичным объявлению в соответствующем определении функции. Это никогда не ошибается, если само определение функции верно.

ТЕМ НЕ МЕНИЕ,

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

2. C89 устарел. Последняя версия стандарта - C 2018; C 2011 широко распространен; а C99 (тоже технически устаревший) доступен практически везде. Возможно, у вас есть веская причина настроить таргетинг на C89, но вам следует настоятельно подумать о том, чтобы вместо этого настроить таргетинг на C11 или C18 или как минимум C99.

Опытным путем в gcc и clang класс хранилища register для параметров функции ведет себя так же, как квалификаторы верхнего уровня для параметров: учитываются только те, которые указаны в определении (не в предыдущем прототипе).

(что касается квалификаторов верхнего уровня, они также отбрасываются, когда рассматривается совместимость типов, т. е. void f(int); и void f(int const); являются совместимыми прототипами, но классы хранения не являются частью типов, поэтому совместимость типов не является проблемой для них в первую очередь )

С точки зрения программиста на C, единственный наблюдаемый результат register в C - это то, что компилятор не позволит вам получить адрес объявленного объекта.

Когда я делаю:

void f(int A, int register B);

void f(int register A, int B) 
{
    /*&A;*/ //doesn't compile => A does have register storage here
    &B; //compiles => B doesn't have register storage here;
        //the register from the previous prototype wasn't considered
}

затем &B компилируется, а &A - нет, поэтому учитываются только квалификаторы в определении.

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

Стандарт C89 говорит об этом (3.5.4.3 Внешние определения):

Единственный спецификатор класса хранения, который должен встречаться в объявлении параметра, - это register.

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

Поскольку вы упомянули Watcom и C89, я предполагаю, что вы ориентируетесь на x86-16. Типичные соглашения о вызовах для x86-16 (pascal, stdcall и cdecl) требуют, чтобы параметры помещались в стек, а не в регистры, поэтому я сомневаюсь, что ключевое слово действительно изменит способ передачи параметров в функцию при вызове. сайт.

Предположим, у вас есть следующее определение функции:

int __stdcall add2(register int x, register int y);

Функция входит в объектный файл как _add2@4 в соответствии с требованиями для stdcall. @ 4 указывает, сколько байтов удалить из стека при возврате функции. В этом случае используется инструкция ret imm16 (возврат к вызывающей процедуре и извлечение байтов imm16 из стека).

add2 будет иметь в конце следующее ret:

ret 4

Если 4 байта не были помещены в стек на месте вызова (т.е. потому что параметры фактически были в регистрах), ваша программа теперь имеет неверно выровненный стек и вылетает.

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

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

gcc myfile.c -S -o myfile.s

Из стандарта C17, 6.7.1 Спецификаторы класса хранения:

Объявление идентификатора для объекта со спецификатором класса хранения register предполагает, что доступ к объекту должен быть как можно более быстрым. Степень эффективности таких предложений определяется реализацией.

Подразумевается, что компилятор попытается, или независимо от компилятора, ускорить доступ к параметрам, но не подразумевает каких-либо изменений в соглашении о вызовах (в основном никаких изменений на вызывающей стороне).

Таким образом, он должен присутствовать в определении функции, но не имеет значения в прототипе.