为什么“stdint.h”的实现不同意UINT8_C的定义？

Question

UINT8_C宏在“stdint.h”中定义，具有以下规范 ： 宏UINTN_C(value)应扩展为对应于uint_leastN_t类型的整数常量表达式。

然而，在野外，实现方式有所不同：

#define UINT8_C(value) ((uint8_t) __CONCAT(value, U))  // AVR-libc
#define UINT8_C(x_)    (static_cast<std::uint8_t>(x_)) // QP/C++
#define UINT8_C(c)     c                               // GNU C Library

前两个实现似乎大致相同，但第三个实现的行为不同：例如，以下程序使用AVR-libc和QP / C ++打印1 ，但使用glibc打印-1 （因为有符号值的右移传播符号位）。

std::cout << (UINT8_C(-1) >> 7) << std::endl; // prints -1 in glibc

UINT16_C的实现显示相同的行为，但不显示UINT32_C ，因为它的定义包括U后缀：

#define UINT32_C(c) c ## U

有趣的是，由于错误报告 ，glibc对UINT8_C的定义在2006年发生了变化。 之前的定义是#define UINT8_C(c) c ## U ，但是由于整数提升规则，在-1 < UINT8_C(0)上产生了错误的输出（ false ）。

这三个定义是否都符合标准？ 这三种实现之间是否存在其他差异（除负处理常量的处理之外）？

Answer 1

如果int可以表示uint_least8_t所有值，那么UINT8_C(value)宏的GNU实现为#define UINT8_C(c) c符合C标准。

根据C11 7.20.4宏对于整数常量第2段：

这些宏的任何实例中的参数都应是未填充的整数常量（如6.4.4.1中所定义），其值不超过相应类型的限制。

例如，如果UINT_LEAST8_MAX为255，则以下用法示例是合法的：

• UINT8_C(0)
• UINT8_C(255)
• UINT8_C(0377)
• UINT8_C(0xff)

但是以下用法示例会导致未定义的行为 ：

• UINT8_C(-1) - 不是6.4.4.1中定义的整数常量
• UINT8_C(1u) - 不是非整数常量
• UINT8_C(256) - 超出了此实现的uint_least8_t的限制

由于相同的原因，带符号的等效INT8_C(-1)也是未定义的行为 。

如果UINT_LEAST8_MAX为255，则UINT8_C(value)的合法实例将扩展为整数常量表达式，并且由于整数提升，其类型将为int ，如第3段所述：

其中一个宏的每次调用都应扩展为适合在#if预处理指令中使用的整数常量表达式。 表达式的类型应与根据整数提升转换的相应类型的表达式具有相同的类型。 表达式的值应该是参数的值。

因此，对于UINT8_C(value)任何合法调用，通过int可以表示uint_least8_t所有value的任何实现将其扩展为值是完全符合标准的。 对于任何非法调用UINT8_C(value) ，由于未定义的行为，您可能无法得到您期望的结果。

[EDIT为完整性添加]正如cpplearner的回答所指出的，OP问题中显示的UINT8_C(value)的其他实现是无效的，因为它们扩展为不适合在#if处理指令中使用的表达式。

Answer 2

前两个实现不符合C标准，因为它们不允许#if指令中的UINT8_C(42) ：

#if UINT8_C(42) == 42 // <- should be a valid expression

N1570 7.20.4 / 3 ：

其中一个宏的每次调用都应扩展为适合在#if预处理指令中使用的整数常量表达式。 表达式的类型应与根据整数提升转换的相应类型的表达式具有相同的类型。 表达式的值应该是参数的值。

Answer 3

GNU C库不正确。 Per C11 7.20.4.1最小宽度整数常量的宏 UINTN_C(value)定义为

宏UINTN_C(value)将扩展为对应于类型uint_leastN_t的整数常量表达式。

所以他们只是使用c是uint_least8_t因为c可能是也可能不是uint_least8_t 。