为什么C编译器指定长为32位，长为64位？
在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
C99 N1256标准草案
long和long long大小是实现定义的，我们都知道：
- 最小尺寸保证
- 类型之间的相对大小
5.2.4.2.1整数类型的大小
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位（这将在现有代码中产生更大的问题）。