问题标签 [c17]

以下代码尝试在两个不同的常量上下文中对字符串文字使用数组索引：

根据 Compiler Explorer 的判断，工具供应商之间有明确的共识，即不允许在明确需要整数常量表达式的第二种情况下执行此操作。但是，它们似乎对第一个上下文有所不同，第一个上下文只是初始化器中使用的算术常量表达式。GCC 和 Clang 作为允许这样做的实现脱颖而出。

这本身并不有趣，因为在6.6 的第 10 段中，C11/C18 确实说“实现可以接受其他形式的常量表达式”。但是，它在这种情况下很突出，因为：

• GCC 和 Clang 都默默地接受了这一点-pedantic（真的，编译器的签名并不意味着代码符合）。构建代码是有道理的，因为它的含义很简单，但是如果他们认为这不符合要求，我会期待一个警告，并且他们可以识别（他们认为）它是否符合要求，因为......

• 对于这两个编译器，行为最近都发生了变化——直到 3.8 之前，Clang 都会引发错误，而 GCC 直到 8.0 之前都会引发错误。这些版本分别于 2016 年和 2018 年问世。这表明更改是故意的，但我还没有找到任何一个编译器的发行说明，其中包含这个级别的详细信息。

行为变化的时机看起来与 C18 有关，但 6.6 的措辞似乎没有改变。对整数常量表达式的限制仍然很严格（如第二行继续错误所示），第 9 段的措辞似乎与 C11 中的相同，特别是继续说“对象的值不得通过使用这些运算符访问”（wrt[]和朋友）。

通过阅读标准，第一个上下文是否是有效的初始化常量，不包括第 10 段？是否有任何地方我可能会找到 GCC/Clang 更改的理由？

我尝试在 openstd org 上谷歌并快速搜索“C lang”和“C18”的最新草案。C++ 标准会支持最新的 C 标准吗？

我知道，最新的官方标准修订版可在：
https ://www.iso.org/standard/74528.html

但是由于http://www.open-std.org -
http://www.open-std.org/JTC1/SC22/WG14/上与 C 语言工作组相关的页面
声称，它是，引用：

ISO/IEC JTC1/SC22/WG14-C的官方主页

其目前的最新更新日期为：

2020-03-30

为什么它仍然说，当前的 C 标准是C11（不是C17或C18）：

当前的 C 编程语言标准 (C11) ISO/IEC 9899 于 2011 年被 ISO 和 IEC 采用。
?

那只是该页面的维护不善吗？或者它不是官方页面，正如它声称的那样？或者工作组没有将 C18 视为标准的真正版本/修订，而是 C11 版本的“错误修复”，仍然是最新版本？

还有一个问题，可能与最初的问题有关。

网络上的不同来源将N2176.pdf文档称为 C18 的最新草案版本，甚至提供指向它的链接。例如，关于 C18 的 Wikipedia 页面提供了指向 www.open-std.org 的 C17 草案存档版本的链接，该 pdf 文档的内容看起来像是真正的 N2176 文档。n2176.pdf然而，当前 www.open-std.org 的实际文档： http ://www.open-std.org/JTC1/SC22/WG14/www/docs/n2176.pdf 很难看，因为它被锁定了密码。同时可以免费查看以前修订的草稿版本。

我们在 C18 标准中读到：

5.1.1.2 翻译阶段

翻译的语法规则之间的优先级由以下阶段指定。

1. 如有必要，物理源文件多字节字符以实​​现定义的方式映射到源字符集（为行尾指示符引入换行符）。

这意味着源文件字符集被解码并映射到源字符集。

但是你可以阅读：

5.2.1 字符集

应定义两组字符及其相关的整理序列：写入源文件的字符集（源字符集）和在执行环境中解释的字符集（执行字符集）。

意思就是源文件字符集就是源字符集。

所以问题是：我理解错了哪一个，或者实际上是哪一个？

编辑：其实我错了。请看下面我的回答。

输出

这是~C17（用我的粗体字）6.5.3.3.4 中的语义。

~ 运算符的结果是其（提升）操作数的按位补码（即，当且仅当未设置转换操作数中的相应位时，结果中的每个位都被设置）。整数提升在操作数上执行，结果具有提升的类型。如果提升的类型是无符号类型，则表达式 ~E 等价于该类型中可表示的最大值减去 E。

这是&C17 6.5.10.3 中一元的语义。

通常的算术转换是在操作数上执行的。

a等于9223372036854775808等于8000 0000 0000 0000(16)。

没有任何后缀的整数常量1与(int)1. 因此~1== ~(int)1== FFFF FFFE(16)（整数提升不会发生在~）。

的类型通过通常的算术转换FFFF FFFE(16)转换为unsigned long longat 。
a = 8000 0000 0000 0000(16) & FFFF FFFE(16)因此
a = 8000 0000 0000 0000(16) & FFFF FFFE(16)==
a = 8000 0000 0000 0000(16) & 0000 0000 FFFF FFFE(16)

最后，
a = a & ~1==
a = 8000 0000 0000 0000(16) & FFFF FFFE(16)==
a = 8000 0000 0000 0000(16) & 0000 0000 FFFF FFFE(16)==
a = 0000 0000 0000 0000(16)

但是输出说好像
a = a & ~1==
a = 8000 0000 0000 0000(16) & FFFF FFFE(16)==
a = 8000 0000 0000 0000(16) & FFFF FFFF FFFF FFFE(16)==
a = 8000 0000 0000 0000(16)

我的问题是如何显示输出？

It may sound obvious, but just out of curiosity: is program translation direction well-defined (i.e. top-to-bottom, left-to-right)? Is it explicitly defined in the standard?

所以我重新阅读了关于有效类型和严格别名的 C17 6.5/6 - 6.5/7，但不知道如何处理限定符。有些事情让我感到困惑：

• 我一直认为限定符与有效类型并不真正相关，因为规则谈到左值访问，这意味着左值转换会丢弃限定符。但是如果对象是一个指针呢？指向数据的限定符不受左值转换的影响。

  Q1：如果有效类型是指向限定类型​​的指针怎么办？我可以将它作为指向同一类型的非限定指针进行左值访问吗？这在标准的什么地方有规定？

• 在这些情况下，严格别名规则的例外情况会提到限定符：

  — 与对象的有效类型兼容的类型的限定版本，
  — 与对象的有效类型对应的有符号或无符号类型，
  — 与限定版本对应的有符号或无符号类型对象的有效类型，

  这些地址限定符都不是有效类型本身，只有用于访问的左值。由于左值转换，这应该是无关紧要的......对吗？

  Q2：左值转换是在上面引用的有效类型/严格别名规则应用之前还是之后发生的？

  Q3：有效类型是否带有限定符？这在标准的什么地方有规定？

我正在看 C17，N2176 的最终草案。在这里，我关心什么样的带有副作用的表达式会导致其行为未定义。

在标准的第 6.5 节表达式中，有第 2 段开头：

如果标量对象上的副作用相对于同一标量对象上的不同副作用或使用相同标量对象的值的值计算是未排序的，则行为未定义。

据我了解，表达式 x=1 的评估既会产生一个值，也会引发一个副作用，改变 x 指定的对象的值。然后，决定因素将是副作用是否以任何方式与使用 x 指定的对象的值的值计算有关。

第 6.5.16 节赋值运算符中的描述包含这句话：

更新左操作数的存储值的副作用是在左操作数和右操作数的值计算之后排序的。

这并不能解决整个赋值的值计算顺序和赋值的副作用。

另外，还有一句话：

赋值表达式在赋值后具有左操作数的值，但不是左值。

指定最终值应该是什么，但不要求任何排序。而且我没有看到任何其他文本提到有关副作用和价值的排序。

我知道当写成完整的陈述时 x=1; 不使用赋值的值。但是，标准说该值被丢弃。这意味着好像首先对值进行评估然后丢弃，因此仍应触发未定义的行为。

标准的任何其他部分是否使该语句行为未定义？

功能fpclassify(x) == FP_NAN上等同于?isnan(x)

同样的问题适用于：

• fpclassify(x) == FP_INFINITE对比isinf(x)
• fpclassify(x) == FP_NORMAL对比isnormal(x)
• fpclassify(x) == FP_SUBNORMAL对比issubnormal(x)
• fpclassify(x) == FP_ZERO对比iszero(x)

如果它们在功能上是等效的，那么为什么需要重复呢？

如果我使用 gcc -std=c17，会-Wpedantic为 c17 发出警告吗？这和 ISO C 一样吗？