Каковы ограничения в стандарте C?

Ответ 1

Являются ли ограничения все, что появляется в разделах под заголовками "Ограничения" ?

В смысле n1570 3.8 (ограничение, налагаемое на программы, для которых требуется соответствующая реализация для выдачи диагностического сообщения времени компиляции при нарушении), я думаю, да.

Является ли каждое требование, которое указано вне этих разделов, не является ограничением?

В смысле 3.8, я думаю, да, но для более круговой причины: стандартная структура довольно формальна. Всякий раз, когда это применимо, существует явный раздел ограничений. Поэтому я понимаю, что по определению все, что не находится в разделе "Ограничения" , не является ограничением в смысле 3.8.
Существует несколько разделов "must" вне разделов Constraints, которые полностью исполняются во время компиляции, ср. ниже для нескольких примеров. Они часто находятся в смежных разделах Семантики. Возможно, мне недостает тонкостей, которые предотвращают обнаружение времени компиляции в общем случае (так что диагноз не может быть обязательным), или, может быть, стандарт не полностью согласован. Но я бы подумал, что компилятор может просто перевести нарушающую программу, именно потому, что требования не находятся в разделе "Ограничения" .

Есть ли исчерпывающее описание ограничения в стандарте, который я пропустил?

Я думаю, что 3.8 - это все, что вы получаете. Я пытаюсь изучить приведенный ниже термин и соглашаюсь с тем, что это определение неудовлетворительное.

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

Термин ограничение

Давайте начнем с основ. Определение "ограничения" в 3.8, которое вы цитируете, на удивление трудно понять, по крайней мере, без контекста ( "ограничение, синтаксическое или семантическое, с помощью которого должно интерпретироваться выражение языковых элементов" ). "Ограничение" и "ограничение" являются синонимами, так что перестановка не добавляет многого; и что подразумевается под "изложением языковых элементов"? Экспозиция - это слово с несколькими значениями; позвольте взять "письмо или речь в первую очередь для передачи информации" из Dictionary.com, и пусть предположим, что они означают стандарт с этим. Тогда это означает, что ограничение в этом стандарте является ограничением того, что сказано в этом стандарте. Ничего себе, я бы не догадался.

Ограничения по 3.8

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

Ограничения во внешних разделах ограничений

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

Есть несколько положений "обязательно", которые налагают ограничения на программу (а не на реализацию) за пределами секций ограничений. Я бы сказал, что большинство относятся к той же категории, что и "ограничения времени выполнения [...] в программе при вызове библиотечной функции", упомянутой в 3.18. Они, похоже, являются ограничениями времени выполнения, которые обычно не обнаруживаются во время компиляции (так что диагностика не может быть обязательной).

Вот несколько примеров.

В 6.5/7 n1570 подробно описываются правила сглаживания:

Объект должен иметь доступ только к сохраненному значению выражением lvalue, которое имеет один из следующие типы:

• тип, совместимый с эффективным типом объекта
• квалифицированная версия совместимого типа с эффективным типом объекта, [...]

В пункте 6.5.16.1 "Простое назначение":

Если значение, хранящееся в объекте, считывается из другого объекта, который каким-либо образом перекрывается хранение первого объекта, то перекрытие должно быть точным [..]. "

Другие примеры относятся к арифметике указателей (6.5.6/8).

Предложения, которые могут быть в разделах Ограничения

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

• 6.6/6, "Операторы Cast в целочисленной константе выражение должно преобразовывать только арифметические типы в целые типы "(в разделе" Семантика "), что вы можете обнаружить во время компиляции, если вы не можете определить типы констант и приведения?
• 6.7/7: "Если идентификатор объекта объявлен без привязки, тип объекта должен быть завершен до конца его декларатора" (в разделе "Семантика" ). Мне кажется, что это основная задача компилятора, чтобы определить, завершен ли тип в какой-то момент кода. Но, конечно, я никогда не писал компилятор C.

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

Ответ 2

Комитет С рассмотрел этот вопрос в ответ на Отчет о дефектах № 033. Вопрос в этом отчете о дефекте:

Является ли соответствующая реализация необходимой для диагностики всех нарушений операторов '' должен '' и '' не должна '' в стандарте, даже если эти утверждения происходят за пределами раздела с надписью "Ограничения?"

Автор этого отчета о дефектах предложил несколько возможных альтернативных способов интерпретации языка стандарта. Второй вариант, который он перечислял, сказал (частично):

Правила синтаксиса - это те элементы, которые перечислены в разделе Синтаксис стандарта. Ограничения - это те элементы, которые перечислены в разделе Ограничения стандарта.

Часть ответа комитета была:

Рекомендуемая интерпретация № 2 является правильной.

Я считаю, что ваши вопросы достаточно справедливы, но просто для того, чтобы напрямую ответить на ваши вопросы:

• Являются ли ограничения все, что появляется в разделах под названием "Ограничения"?
• Является ли каждое требование, которое указано вне этих разделов, не является ограничением?

"Ограничение" - это требование, указанное в разделе, явно помеченном "Ограничения". Любое требование, указанное за пределами такого раздела, не является ограничением.

• Есть ли исчерпывающее описание ограничений в стандарте, который я пропустил?

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

Ответ 3

Являются ли ограничения все, что появляется в разделах под заголовками "Ограничения"?

Похоже, что они в основном (есть некоторые случаи, которые не являются, fx: он заявил, что "Incrementing эквивалентно добавлению 1" в одном из разделов ограничений).

Является ли каждое требование, которое указано вне этих разделов, не является ограничением?

Я не видел "ограничения" вне этих разделов.

Есть ли исчерпывающее описание ограничения в стандарте, который я пропустил?

Наверное, нет, если бы были такие авторитетные, то они были бы в стандарте и, вероятно, были бы секциями "ограничения" (и явно упоминали, что это все "ограничения" ).

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

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

Однако, как представляется, существует немало примеров "должно" и "не должно", которые могут быть приняты такими ограничениями, которые явно не называются таковыми. Это оставило бы все случаи "должны" и "не должны" требовать или запрещать определенное поведение реализации - и если они не выполняются, то да, поведение может быть undefined (поскольку вы используете реализацию, которая не соответствует стандарту).

Похоже, что все, что соответствует определению "ограничение" , похоже, встречается в разделе "ограничение" , и все разделы "ограничения" кажутся "ограничениями".

Ответ 4

Являются ли ограничения все, что появляется в разделах под заголовком Ограничения?

Да. Все синтаксические и семантические ограничения, упомянутые в стандарте, являются ограничениями.

Например, ограничение на константные выражения (C11-6.6/3):

Константные выражения не должны содержать операции присваивания, приращения, декремента, функции-вызова или запятой, кроме случаев, когда они содержатся в недовыраженном подвыражении. ¹¹⁵⁾

Следовательно, постоянные выражения

3 = 5;
10++;

показывает нарушение ограничений.

Обратите внимание, что в этом случае требование должно, а также ограничение нарушаются.

Является ли каждое требование, которое указано вне этих разделов, не является ограничением?

Для стандартного соответствия C, да. Требование A к целочисленному постоянному выражению (C11-6.6/6):

Целочисленное константное выражение ¹¹⁷⁾ должно иметь целочисленный тип [...]

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

int arr[5+1.5];

нарушает требование. Тип выражения 5+1.5 не является целым типом. Это требование должно быть ограничено.

Следует отметить, что требование a также может быть ограничением.

Ответ 5

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

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

Требование является частью спецификации поведения раздела стандарта. "Должен" - положительное описание того, что требуется; "не должен", как правило, ограничивать, но не ограничивать - он может участвовать, хотя и встречает ограничение на его вывод.

Ограничения и требования можно рассматривать как "внешние интерфейсы" (ограничения) и "поведение/обработка системы" (требования).

Как правило, это означает требование (фраза без "должна", следовательно, не является требованием). "Shall", используемое в ограничении, либо используется для определения ввода или вывода (например, argc должно быть положительным), либо указывает поведение, относящееся к проверке ограничения (например, "... должно дать диагностическое сообщение" ).

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

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

Это может быть личное представление, но, похоже, оно соответствует использованию этих слов в стандарте.

Ответ 6

ограничение

ограничение, синтаксическое или семантическое, с помощью которого изложение языковых элементов должно интерпретироваться

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

Является ли каждое требование, указанное за пределами этих разделов, не ограничение?

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

Существует ли полное описание ограничений в стандарте что я пропустил?

Насколько мне известно.