标准 C 中的约束是什么？

Question

C 标准谈​​论约束，例如。 G。 ISO/IEC 9899:201x 定义了术语

约束
限制，无论是句法还是语义，通过它 语言元素的阐述将被解释

并在符合性

一章中说

如果“应”或“不应”要求出现在 约束或运行时约束被违反，行为是 未定义。

在Environment一章的Diagnostics小节中提到

符合要求的实现应至少产生一个诊断 消息（以实现定义的方式标识）如果 预处理翻译单元或翻译单元包含一个 违反任何语法规则或约束，即使行为是 也明确指定为未定义或实现定义。

因此，了解 C 中的约束是很重要的，例如，编译器编写者可以判断何时需要诊断，或者 C 程序员何时可以预期诊断，而不仅仅是未定义的行为。
现在，标准文档中到处都有标题为 Constraints 的部分，但我无法找到明确的措辞来说明标准中的术语 constraint 究竟涵盖了哪些内容。

• 标题是约束部分中出现的所有约束吗？
• 在这些部分之外陈述的每个要求都不是限制条件吗？
• 我错过的标准中有没有对约束的全面描述？

Answer 1

所有的约束都出现在标题为“约束”的部分中吗？

在 n1570 3.8 的意义上（对程序施加的限制，需要符合要求的实现在违反时发出编译时诊断消息），我认为是的。

在这些部分之外陈述的每个要求都不是约束吗？

在 3.8 的意义上，我认为是的，但出于更循环的原因：标准的结构相当正式。只要适用，似乎就有一个明确的 Constraints 部分。因此，我理解 根据定义 任何不在 Constraints 部分中的东西都不是 3.8 意义上的约束。
Constraints 部分之外有一些“shall”子句，它们看起来完全可以在编译时强制执行，参见。下面举几个例子。它们通常位于相邻的语义部分中。我可能会遗漏在一般情况下阻止编译时检测的细微之处（因此不能强制进行诊断），或者标准可能不完全一致。但我认为编译器可以简单地翻译违规程序，正是因为要求不在约束部分中。

我错过的标准中有没有对约束的全面描述？

我认为 3.8 就是你得到的全部。我尝试探索以下术语并同意该定义不令人满意。

---

我深入研究了标准以找出答案。这是我的研究。

术语约束

让我们从基础开始。您引用的 3.8 中“约束”的定义令人惊讶地难以理解，至少在没有上下文的情况下（“限制，句法或语义，通过它来解释语言元素的阐述”）。 “限制”和“约束”是同义词，因此重新措辞并没有增加太多； “语言元素的展示”是什么意思？说明是一个有多种含义的词；让我们以Dictionary.com 的“主要用于传达信息的写作或演讲”为例，假设它们的意思是标准。那么它基本上意味着该标准中的 约束 是对该标准中所说内容的约束。哇，我没想到。

约束 根据 3.8

只要检查标准中的实际约束部分，就会发现它们列出了对符合程序施加的编译时间限制。这是有道理的，因为只能在编译时检查编译时约束。 这些附加限制是那些不能用 C 语法表达的限制。¹

约束部分之外的约束

约束部分之外的“应”的大多数用法对符合的实现施加限制。示例：“所有具有静态存储持续时间应初始化（设置为 初始值）在程序启动之前”，一个符合要求的实现的工作。

在 Constraints 部分之外，有一些“shall”子句对 program（不是实现）施加了限制。我认为大多数与 3.18 中提到的“调用库函数时程序上的运行时约束 [...]”属于同一类别。它们似乎是在编译时通常无法检测到的运行时限制（因此诊断不是强制性的）。

这里有几个例子。

在 6.5/7 n1570 中详细介绍了备受争议的别名规则：

一个对象只能访问其存储的值 通过具有以下之一的左值表达式 以下类型：

• 与对象的有效类型兼容的类型
• 类型兼容的合格版本 与对象的有效类型， [...]

在 6.5.16.1 中，“简单赋值”：

如果存储在一个对象中的值是从另一个以任何方式重叠的对象中读取的 第一个对象的存储，那么重叠应该是精确的[..]。”

其他示例涉及指针算法 (6.5.6/8)。

Shall 子句可以在 Constraints 部分中

但是还有其他的 should 子句，它们的违反应该在编译时被检测到；如果它们出现在相应的约束部分，我不会眨眼。

• 6.6/6, "整数常量中的转换运算符 表达式只能将算术类型转换为整数类型”（在“语义”下）；如果您无法检测常量和强制类型转换，您可以在编译时检测到什么？
• 6.7/7，“如果声明对象的标识符时没有链接，则对象的类型应在其声明符的末尾完成”（在“语义”下）。对我来说，这似乎是一项基本的编译器任务，用于检测代码中某个类型是否完整。当然，我从来没有写过 C 编译器。

还有几个例子。但正如我所说，我认为诊断违规行为不需要实现。设法偷偷溜过编译器的违规程序只会暴露未定义的行为。

---

_{¹ 例如，我知道语法不处理类型——它只有通用的“表达式”。因此，每个运算符都有一个 Constraints 部分，详细说明其参数的允许类型。移位运算符的示例：“每个操作数都应具有整数类型。” 尝试对浮点数进行移位的程序违反了此约束，实现必须发出诊断。子>}

Answer 2

C 委员会在回复 Defect Report # 033 时解决了这个问题。该缺陷报告中的问题是：

是否需要符合标准的实现来诊断标准中所有违反“应”和“不应”语句的行为，即使这些语句出现在标记为“约束”的部分之外？

该缺陷报告的作者提出了几种解释标准语言的可能替代方法。他列出的第二种选择（部分）说：

语法规则是标准的语法部分中列出的那些项目。 约束是标准的约束部分中列出的那些项目。

委员会的部分回应是：

建议的解释 #2 是正确的。

我相信这相当完整地涵盖了您的问题，但只是为了更直接地回答您的问题：

• 所有的约束都出现在标题为“约束”的部分中吗？
• 在这些部分之外陈述的每个要求都不是限制条件吗？

“约束”是在明确标记为“约束”的部分中说明的要求。在此类部分之外说明的任何要求都不是约束。

• 我错过的标准中是否有全面的约束描述？

至少据我所知，标准本身不包含关于什么是或不是约束的更具体的声明，但链接的缺陷报告包含。

Answer 3

所有的约束都出现在标题为“约束”的部分中吗？

似乎它们大多是（有些情况不是，fx：在其中一个约束部分中声明“递增等于加 1”）。

在这些部分之外陈述的每个要求都不是约束吗？

我没有看到这些部分之外的“约束”。

我错过的标准中是否有关于约束的全面描述？

可能不会，如果有这样的权威，它将在标准中并且可能是“约束”部分（并明确提到这些都是“约束”）。

我的解释是，第 3 章的解释应使定义的术语的每次使用都具有该部分中定义的含义。尤其是在使用“约束”一词的任何地方，都应该根据您的第一句话来理解。

您的第二个报价也不例外。在术语“约束”的定义中指出，不要求将约束明确称为约束。这意味着您必须通过检查它是否是这样的限制来确定它是否是“限制”。

然而，似乎有相当多的“应该”和“不应”的例子可以被认为是这样的限制，而没有明确地这样称呼。这将使所有发生的“应”和“不应”强制或禁止实现的某种行为 - 如果这些没有实现，那么是的，行为可能是未定义的（因为您使用的实现不t符合标准）。

看起来符合“约束”定义的所有内容似乎都出现在“约束”部分下，而“约束”部分中的所有内容似乎都是“约束”。

Answer 4

所有的约束都出现在标题为约束的部分吗？

是的。标准中提到的每个句法和语义限制都是约束。

例如，对常量表达式的约束 (C11-6.6/3)：

常量表达式不应包含赋值、递增、递减、函数调用或逗号运算符，除非它们包含在未计算的子表达式中。¹¹⁵⁾

因此，常量表达式

3 = 5;
10++;

显示违反约束。

请注意，在这种情况下，shall 要求以及 constraint 都被违反了。

在这些部分之外陈述的每个要求都不是约束吗？

对于符合标准的 C，是的。 A shall 对整数常量表达式的要求 (C11-6.6/6)：

整数常量表达式¹¹⁷⁾应具有整数类型 [...]

例如，非可变长度数组的大小需要整数常量表达式。因此，

int arr[5+1.5];

违反应要求。表达式5+1.5 的类型不是整数类型。这个shall的要求是不受约束的。

需要注意的是，shall 要求也可能是一个约束。

Answer 5

在我的需求工程工作中，“约束”和“需求”这两个词有不同的范围。对于标准来说，明确定义这些也很重要。我在标准中搜索了“约束”一词，似乎可以得出以下结论：

约束是对标准部分描述的行为的输入（前置条件）或输出（后置条件）的限制。对于输入，这意味着输入必须遵守约束（例如，argc 应为正数）。对于输出，这意味着它必须满足标准的任何后续单元的约束才能具有明确定义的输入（其前提条件）。

要求是标准部分行为规范的一部分。 “Shall”是对所需内容的正面描述； “不应”通常是一种限制，但不是一种约束——它可能会参与满足其输出的约束。

约束和要求可以看作是“外部接口”（约束）和“系统行为/处理”（要求）。

Shall 通常表示要求（没有“shall”的短语因此不是要求）。然后，约束中使用的“应”用于定义输入或输出（例如，argc 应为正数）或指定有关验证约束的行为（例如“...应给出诊断消息”）。

严格来说，用于指定验证输入约束的行为的“shall”不应列在约束部分（不应列在接口规范中），而应列在处理部分（行为部分）中。

请注意，不能验证输出约束，因为输出应符合规范；如果这些约束在其输入约束中，则只有下一个 uit 可以检查这些约束。

这可能是个人观点，但似乎符合标准中这些词的用法。

Answer 6

约束

句法或语义上的限制， 语言元素的阐述将被解释

这意味着c标准以任何方式设置的程序逻辑或语法的每个显式限制都是一个约束。这包括语法约束（例如，块必须以; 终止）和语义约束（例如，在初始化变量之前不得使用变量），基本上是语法（符号）或语义（使用正确符号）的所有内容-wise) 不允许或定义为不允许（未定义的行为）。

在这些部分之外陈述的每个要求不是 约束？

我确实认为 C 语言编程的所有明确要求都属于句法或语义约束。

标准中是否有对约束的全面描述 我错过了什么？

据我所知。

Answer 7

标准中约束的目的是指定符合要求的实现需要发出诊断的条件，或者允许实现以与在没有约束的情况下所需的方式相反的方式处理程序可能比其他指定的行为有用。虽然严格符合 C 程序不允许违反约束（没有违反约束的程序是严格符合 C 程序），但没有此类限制适用于旨在符合但不是严格符合的程序。

C 标准是作为多个重叠派系之间的妥协而编写的，包括

1. 那些认为它应该阻止程序员编写不能在所有平台上互换使用的代码的人
2. 那些认为它应该允许以已知平台为目标的程序员利用他们需要支持的所有平台共有的功能，即使它们不能在所有平台上都支持
3. 那些认为应该允许编译器诊断构造和操作的人，这些构造和操作会更频繁地被意外执行而不是故意执行
4. 那些认为它应该允许程序员执行诸如执行地址计算之类的事情的人，这些事情看起来是错误的，但如果按照指定的方式精确执行，就会产生程序员所期望的对象的地址。

为了在这些群体之间达成共识，标准对在严格符合 C 程序中可以做的事情施加了限制，但同时也将符合 C 程序的定义写得足够宽泛，几乎没有有用的程序会被标记为不符合无论他们所依赖的扩展多么晦涩难懂。如果源代码构造违反了可诊断的约束，但实现的客户无论如何都会发现它有用，那么实现可以输出其客户可以忽略的诊断（甚至是无条件的：“警告：此实现不会打扰输出诊断它的作者认为是愚蠢的，除了这个“就足够了），每个人都可以继续生活。