问题标签 [c17]

How to determine w/o conversions that a given floating constant can be represented?

Sample code:

示例代码（t4.c）：

调用：

问题：为什么不能long long用 print初始化LLONG_MIN？怎么修？

N2479 C17..C2x 工作草案 — 2020 年 2 月 5 日 ISO/IEC 9899:202x (E)：F.3 操作，9：

与 fegetround 和 fesetround 函数以及 FENV_ROUND pragma 一起使用的宏 (7.6) FE_DOWNWARD、FE_TONEAREST、FE_TONEARESTFROMZERO、FE_TOWARDZERO 和 FE_UPWARD 分别表示 IEC 60559 舍入方向属性 roundTowardNegative、roundTiesToEven、roundTowardZero 和 roundTowardPositive . 对二进制浮点运算的 roundTiesToAway 属性的支持，因此对 FE_TONEARESTFROMZERO 宏的支持是可选的。

让我们回顾一下：

问题：句子#1 列出了 5 个FE_宏，后跟 4 个以“分别”结尾的 IEEE 754 舍入方向属性。

是错误/错字吗？拥有该标准最新发布版本的人可以检查它吗？

众所周知：

• 函数的隐式声明无效
• 变量的隐式声明无效

哪些隐式声明是允许/有效的？

一个例子是标识符__func__。还有其他例子吗？

如果违反了“应该/不应”的要求，那么这种要求位于哪个部分（例如语义、约束）是否重要？

问题的原因：这个意见：

这是标准的语义部分，而不是约束，因此不需要诊断。

是否违反语义部分中的“应/不应”要求不需要诊断？

后续问题：如果违反了“应/不应”要求，那么该要求位于哪个部分（例如语义、约束）是否重要？.

ISO/IEC 9899:202x (E) 工作草案——2020 年 12 月 11 日 N2596，5.1.1.3 诊断，1：

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

结果：语义违规不需要诊断。

问题：“语义违规不需要诊断”的（可能）理由是什么？

C17 标准说

如果翻译单元包含一个或多个标识符的暂定定义，并且翻译单元不包含该标识符的外部定义，则行为与翻译单元包含该标识符的文件范围声明完全相同，复合类型为翻译单元的末尾，初始化器等于 0。

这不会导致外部链接标识符出现问题吗？例如，如果您有int i4; // tentative definition, external linkage一个包含在两个文件中的标头，但在任何地方都没有任何定义。根据该子句的措辞方式，您现在似乎int i4 = 0在每个翻译单元中都有一个有效的定义，这会导致多重定义错误。它没有提到在不同的翻译单元中定义的变量阻止了这种隐含的行为。

我使用 msvc 2019 作为工具链。

下面的程序编译没有错误。

有趣unsigned long my_addr = (unsigned long)addr_b - (unsigned long)addr_a的是，当我设置编译器时抛出“错误：初始化元素不是常量”。

我知道全局变量只能用常量表达式初始化。我也知道可以在全局初始化器中使用的常量表达式的类型在C 标准的第 6.6p7 节中指定：

初始化器中的常量表达式允许更大的自由度。这样的常量表达式应为或评估为以下之一：

• 算术常数表达式，
• 一个空指针常量，
• 地址常量，或
• 完整对象类型的地址常量加上或减去整数常量表达式。

请注意，允许使用地址常量减去整数常量，但不允许使用地址常量减去另一个地址常量。

问题：

为什么 C 标准会限制初始化全局变量的方式？是什么阻止了 C 标准的接受unsigned long my_addr = (unsigned long)addr_b - (unsigned long)addr_a？

你为什么要这个？

假设addr_a并分别addr_b表示该.text部分的开始和结束。程序可能想要映射.text具有 size 的部分(unsigned long)addr_b - (unsigned long)addr_a。trust-firmware-a项目在 Boot Loader 阶段 2 (BL2) 中执行此操作。请参阅BL_CODE_END - BL_CODE_BASE，它在arm_bl2_setup.c中使用。

我有一个 C 项目的源代码，其中包含 600 多个 c 文件，它使用 GCC 工具链为 ARM mcu 编译。我想知道如何才能最接近地猜测这个 c 项目符合 C99、C11 和 C17 中的哪个 C 标准？

我注意到 C17 标准似乎包含+=关于原子类型的复合赋值（等）的原子性的矛盾说明。

从据称是最终工作草案的N2176草案开始，6.5.16.2p3 具有：

如果 E1 具有原子类型，则复合赋值是具有 memory_order_seq_cst 内存顺序语义的读-修改-写操作。

并且 7.17.3p12 保证了读取-修改-写入操作的通常“原子”语义：

原子读-修改-写操作应始终读取在与读-修改-写操作关联的写之前存储的最后一个值（按修改顺序）。

（我也查过，5.1.2.4p5 中定义的术语是“read-modify-write”，基于斜体的使用，而不是“atomic read-modify-write”。）

但是，在 7.17.7.5 中，在讨论atomic_fetch_*函数时，我们在 p5 中有以下注释：

注意 atomic_fetch 和 modify 泛型函数的操作几乎等同于相应 op = 复合赋值运算符的操作。唯一的区别是复合赋值运算符不能保证原子操作，复合赋值运算符产生的值是对象的更新值，而 atomic_fetch 和 modify 泛型函数返回的值是之前的值原子对象。[强调我的]

这似乎与 6.5.16.2p3 相矛盾，后者实际上说复合赋值运算符确实是原子操作的。我知道注释不规范，所以如果有冲突，6.5.16.2p3 会占上风。但我想知道这是否只是 7.17.7.5p5 中的一个简单错误或缺陷，还是我遗漏了一些微妙之处。

C++23 草案 N2731 有相同的措辞。

[重读，也许他们只是想指出非原子类型上的复合赋值运算符不是原子操作的？但这仍然令人困惑，根据 7.17.7.5p1，这些atomic_fetch_*指令首先仅适用于原子整数类型。]