在128位数字变为现实之前，长64位并保留很长时间是不是更有意义？
是的，它确实有意义，但微软有自己的理由将“长”定义为32位。
据我所知，在目前所有主流系统中，Windows是唯一一个“长”为32位的操作系统。在Unix和Linux上，它是64位的。
Windows的所有编译器都将在Windows上“长”编译为32位，以保持与Microsoft的兼容性。
因此，我避免使用“int”和“long”。偶尔我会使用“int”表示错误代码和布尔值（在C中），但我从不将它们用于任何依赖于类型大小的代码。
c标准没有指定原始数据类型的位长，但只指定了它们的最小位长。因此编译器可以选择原始数据类型的位长度。在确定每个原始数据类型的位长时，编译器设计者应该考虑几个因素，包括计算机体系结构。
这里有一些参考：http://en.wikipedia.org/wiki/C_syntax#Primitive_data_types
由于历史原因。很长一段时间（双关语），“int”意味着16位;因此“长”为32位。当然，时代变了。因此“漫长”:)
PS：
GCC（和其他）目前支持128位整数为“（u）int128_t”。
PPS：
以下是对GCC成员做出决策的原因的讨论：
http://www.x86-64.org/pipermail/discuss/2005-August/006412.html
long和long long的大小是实现定义的，我们都知道：
5.2.4.2.1整数类型的大小<limits.h>给出了最小尺寸：
1 [...]它们的实施定义值的大小（绝对值）应等于或大于[...]
- UCHAR_MAX 255 // 2 8 - 1
- USHRT_MAX 65535 // 2 16 - 1
- UINT_MAX 65535 // 2 16 - 1
- ULONG_MAX 4294967295 // 2 32 - 1
- ULLONG_MAX 18446744073709551615 // 2 64 - 1
6.2.5类型然后说：
8对于具有相同签名和不同整数转换等级的任何两个整数类型（参见6.3.1.1），具有较小整数转换等级的类型的值范围是另一种类型的值的子范围。
和6.3.1.1布尔值，字符和整数确定相对转换等级：
1每个整数类型都有一个整数转换等级，定义如下：
- long long int的等级应大于long int的等级，该等级应大于int的等级，其应大于short int的等级，short rank应大于signed char的等级。
- 任何无符号整数类型的等级应等于相应的有符号整数类型的等级（如果有的话）。
- 对于所有整数类型T1，T2和T3，如果T1的秩大于T2且T2的秩大于T3，则T1的秩大于T3
自从用于通用可重编程微型计算机的第一个C编译器的时代以来，代码通常需要使用精确保持8位，16位或32位的类型，但直到1999年标准没有明确提供程序指定的任何方式。另一方面，几乎所有8位，16位和32位微机的编译器都将“char”定义为8位，将“short”定义为16位，将“long”定义为32位。它们之间唯一的区别是“int”是16位还是32位。
虽然32位或更大的CPU可以使用“int”作为32位类型，而将“long”作为64位类型使用，但是存在大量代码，其预期“long”将是32位。虽然C标准在1999年增加了“固定大小”类型，但标准中还有其他地方仍然使用“int”和“long”，例如“printf”。虽然C99添加了宏来为固定大小的整数类型提供正确的格式说明符，但是有大量代码需要“％ld”是int32_t的有效格式说明符，因为它几乎可以在任何8位上运行，16位或32位平台。
是否更有意义的是“长”为32位，不考虑现有代码库可追溯到几十年，或64位，以避免需要更冗长的“long long”或“int64_t”来识别64位类型可能是一个判断调用，但鉴于新代码在实际应用中可能有利于使用指定大小的类型，我不确定我看到“长”64位的强大优势，除非“int”也是64位（这将在现有代码中产生更大的问题）。
d 32位微计算机将“char”定义为8位，将“short”定义为16位，将“long”定义为32位。它们之间唯一的区别是“int”是16位还是32位。
虽然32位或更大的CPU可以使用“int”作为32位类型，而将“long”作为64位类型使用，但是存在大量代码，其预期“long”将是32位。虽然C标准在1999年增加了“固定大小”类型，但标准中还有其他地方仍然使用“int”和“long”，例如“printf”。虽然C99添加了宏来供应