标准C预处理器如何解释；0xFFFFFFFF"；？

标准C预处理器如何解释“0xFFFFFFFF”：4G-1或-1

对“~0”来说也是一样的问题

如果答案是-1，那么如何将其解释为4G-1（即，除了显式使用4294967295之外，还有其他方法吗）

附言：我在MS Visual Studio上试过（当然是使用比较而不是调用“printf”，因为后者只是根据指定的“%”打印），答案是4G-1。但我不确定微软VisualStudio是否使用标准的C预处理器

---

谢谢

ANSI C很少保证各种核心数据类型的大小，因此依靠

cpp

以这种或那种可移植的方式解释上述值是错误的。如果按下，请考虑将其包装在支票中：

#if 0xFFFFFFFF == -1
...
#else
...
#endif

---

预处理器在强制执行之前不会解释数字。书写

 #define N  0xffffffff

在任何使用

N

的地方都是简单的文本替换，但预处理器

#if

求值除外。C对该值的作用很可能是您想要问的。比如说,

 long number = N;  // declare and initialize to symbolic value N

这可能会导致编译警告，也可能不会导致错误，具体取决于

长度的大小以及编译器转换初始化常量的灵活性。
根据C 2011（N1570）6.10.1 4，在预处理器中计算的整数表达式使用实现中最广泛的类型（
intmax\u t
和
uintmax\u t
）。
0xFFFFFFFF
将具有值232-1，因为每个C实现都必须支持该值，因为
无符号长
~0
在任何正常C实现中都不会具有该值

表达式仅在预处理器中对
#if
和
#elif
语句求值。问题中的文本表示您正试图打印预处理器求值产生的某些表达式。这不会发生。源文本中
#if
和
#elif
语句之外的常量表达式是由常规C规则计算，而不是由预处理器计算。
就预处理器而言，
0xFFFFFFFF
只是一个十六进制常量。预处理器表达式中的数字（仅在
\if
和
\elif
指令中相关）被视为最广泛的可用整数类型；预处理器将把
0xFFFFFFFF
视为带符号整数常量，其值为232-1，或
4294967295
（因为从C99开始，始终存在至少64位的整数类型）

如果它出现在
#If
或
#elif
指令以外的任何位置，则预处理器不相关。十六进制常量的类型为以下类型中的第一个：


int
unsigned int
long int
unsigned long int
long-long-int
无符号长整型

对于该特定常数，有几种可能性：


如果
int
小于32位且
long
大于32位，则类型为
long
如果
int
小于32位且
long
正好是32位，则类型为
无符号长
如果
int
为32位，则类型为
无符号int
如果
int
大于32位，则类型为
int

在现代系统中，
unsigned int
和
unsigned long
是最可能的选择

在所有情况下，
0xFFFFFFFF
的值正好是232-1，或
4294967295
；它从来没有负值

但是，通过将
0xffffff
的值（显式或隐式）转换为有符号类型，可以轻松获得负值（例如，
-1
）：

int n = 0xFFFFFFFF;

但这是不可移植的。如果
int
大于32位，则存储的值将是232-1。即使
int
正好是32位，将无符号值转换为有符号类型的结果也是实现定义的；
-1
是一个常见结果，但不能保证

对于
~0
，这是一个
int
表达式，其值的所有位都设置为1——这通常是
-1
，但这不能保证

你到底想做什么？
我不知道4G-1应该是什么？你假设位模式存在差异，并且编译器没有正确地将位模式放置在变量中？答案是没有差异，它与编译器无关，与程序员也没有任何关系。如果您通过代码告诉编译器将位模式解释为有符号值，然后得到-1；如果您通过代码告诉编译器将同一变量/位模式解释为无符号，则得到无符号值2^32-1。该测试不会表明
0xffffff
已被解释为-1。在C实现中在这种情况下，
0xFFFFFFFF
的值为4294967295，但
-1
被转换为无符号，产生了一个真实的结果。这是不希望的，因为
0xFFFFFFFF
具有所需的值。感谢您的更正。这又是一个棘手问题的证明这些转换的性质。“4G-1”是指“4*（1024）^3-1”或“4G字节减1”，相当于2^32-1或UINT32_MAX。它不是一个标准符号，但在上下文中相当明确。我不想打印它（使用“%u”时只会产生正数，使用“%d”时会产生负数）。我的目标是在代码中有一个常量值（我不在乎它是由预处理器还是由编译器计算的），并在编译过程中将其与无符号整数变量进行比较