我可以假设长整型的大小总是4个字节？
long int （据我所知是一个long的同义词）是否总是为4个字节？
我可以依靠吗？ 如果不是的话，对于一个基于POSIX的操作系统来说可能是真的吗
除了char之外，标准没有提及任何整数types的确切大小。 通常情况下，32位系统上是32位，64位系统上是64位。
该标准确实规定了最小尺寸。 C标准第5.2.4.2.1节：
1下面给出的值应该被适用于
#if预处理指令的常量expression式替代。 而且，除了CHAR_BIT和MB_LEN_MAX，下面的expression式将被replace为与根据整数升级转换的对应types的对象的expression式具有相同types的expression式。 它们的实现定义的值应该等于或大于所示的数值（绝对值），具有相同的符号。…
long inttypes的对象的最小值
LONG_MIN-2147483647 // – （2 ^ 31-1）
long inttypes的对象的最大值
LONG_MAX+2147483647 // 2 ^ 31-1
这就是说， long int 必须是32位的最小值，但可能会更大。 在CHAR_BIT为8的机器上，这会使最小字节大小为4.但是在例如CHAR_BIT等于16的计算机上， long int可能是2个字节。
这是一个真实世界的例子。 对于下面的代码：
#include <stdio.h> int main () { printf("sizeof(long) = %zu\n", sizeof(long)); return 0; }
输出在Debian 7 i686上：
sizeof（long）= 4
在CentOS 7 x64上的输出：
sizeof（long）= 8
所以不，你不能对尺寸做任何假设。 如果您需要特定大小的types，则可以使用stdint.h定义的types。 它定义了以下types：
-
int8_t：有符号的8位 -
uint8_t：无符号的8位 -
int16_t：有符号16位 -
uint16_t：无符号的16位 -
int32_t：有符号的32位 -
uint32_t：无符号的32位 -
int64_t：有符号的64位 -
uint64_t：无符号的64位
标准的第7.20节描述了stdint.h头文件，在第7.20.1.1节中有精确的宽度types。 标准规定这些types定义是可选的，但是它们存在于大多数的实现中。
不，C标准和POSIX都不能保证这一点，事实上大多数类似Unix的64位平台都有64位（8字节）的long 。
使用代码sizeof(long int)并检查大小。 它会给你在你当前工作的系统上的长整型字节的大小。 你的问题的答案特别是没有。 在C或POSIX或任何地方都无法保证。
正如@delnan所指出的那样，POSIX实现将long和int的大小保持为未指定的大小，并且在32位和64位系统之间通常是不同的。
long的长度大多与硬件相关（通常与CPU上的数据寄存器的大小相匹配，有时与OSdevise和ABI接口等其他软件相关的问题相匹配）。
为了简化你的思想， sizeof不是一个函数，而是一个编译器指令*，所以你的代码在使用sizeof时不会使用操作 – 这与编写一个数字是一样的，只是它是可移植的。
使用：
sizeof(long int)
*正如Dave在注释中所指出的那样， sizeof将在运行时被计算出来，在编译过程中不可能计算出这个值，比如使用可变长度的数组。
另外，正如另一条评论指出的那样， sizeof考虑到了实现使用的填充和alignment，这意味着实际使用的字节可能与内存中的大小不同（当位移时这可能是重要的）。
如果你正在寻找特定的字节大小的variables，可以考虑使用一个字节数组或者（我假设被支持）由stdint.h的C99定义的types – 正如@dbush所build议的那样。
当我们在ICL 39系列硬件上首次实现C时，我们采用了标准，并将数据types映射到该机器体系结构上的自然表示，即short = 32位， int = 64位， long = 128位。
但是我们发现没有严重的C应用程序工作。 他们都假设映射short = 16， int = 32， long = 64，我们必须改变编译器来支持。
所以无论官方的标准如何，多年来每个人都已经收敛了long并且不可能改变。
标准中没有提到long int的大小，所以它依赖于你正在使用的环境。
要在你的环境中获得long int的大小，你可以使用sizeof运算符并获得long int的大小。 就像是
sizeof(long int)
C标准只需要关于types大小的以下几点
- int> = 16位，
- 长> = 32位，
- 很长（从C99开始）> = 64位
- sizeof（char）<= sizeof（short）<= sizeof（int）<= sizeof（long）<= sizeof（long long）
- sizeof（char）== 1
- CHAR_BIT> = 8
剩下的就是定义的实现了，所以如果遇到一些int有18/24/36/60位，补码签名的系统，sizeof（char）== sizeof（short）== sizeof（int）== sizeof（long）== 4，48位长或9位字符，如标准委员会关心的Exotic体系结构，以及C标准支持的平台列表
关于long int以上的观点是完全错误的。 大多数Linux / Unix实现定义为64位types，但在Windows中只有32位，因为它们使用不同的数据模型（在这里查看64位计算表），而不考虑32位或64位OS版本。
资源
编译器根据硬件和操作系统的types确定大小。
所以，不应该假设大小。
来自Usrmisc的博客：
该标准完全取决于编译器，这也意味着相同的编译器可以使其依赖于选项和目标体系结构。
所以你不能。
顺便说一句long int和long 。
简答：不！ 你不能对long int的大小做出固定的假设。 因为，标准（C标准或POSIX）不logginglong int的大小（反复强调）。 只是为了提供一个反例，大多数64位系统的长度都是64！ 最大限度地提高可移植性使用sizeof 。
使用sizeof(long int)来检查大小，它返回long的大小（以字节为单位）。 价值是系统或环境的依赖; 也就是说，编译器根据硬件和操作系统来确定大小。
