在x86/amd 64世界中，sizeof(long long)是8。
让我引用8岁的mail by Zack Weinberg的话：
斯科特罗伯特拉德写道：
在64位AMD 64架构上，GCC将long long定义为64位，与long相同。
考虑到某些64位指令（乘法）产生128位结果，将long long定义为128位似乎不符合逻辑吗？
不，原因有二：
1.选择64位'long long'已写入大多数LP 64型号操作系统的ABI;我们不能单方面改变它。
1.这实际上是正确的选择，因为它消除了使'long'不是最广泛的基本整型的偏差。有很多很多代码都是针对sizeof(long) >= sizeof(size_t)的假设编写的-这至少有可能被ABI打破，其中long long比long宽。
(This在C99的开发过程中，“long long”是一个极具争议的主题。据我所知，从外部的Angular 来看，“long long”只是在微软的压力下才被标准化的，微软出于某种原因不能实现LP 64模型。其他所有人都讨厌让“long”不一定是最广泛的基本整型的想法。）
目前最好的实践似乎是提供一个“扩展整型”__int128，它没有“long long”的问题，因为它不是一个 basic 整型（特别是，它不能用于size_t）。
中纬
long long是最广泛的basic整型类型，在我所知道的任何非过时的架构/ABI上它都是64位长，这允许使用简单的跨平台（至少对于许多32/64位架构）typedefs：

typedef char               s8;
typedef unsigned char      u8;
typedef short              s16;
typedef unsigned short     u16;
typedef int                s32;
typedef unsigned int       u32;
typedef long long          s64;
typedef unsigned long long u64;

比intXX_t更好，因为：

• 它们在不同的平台上对64位整数使用相同的基础类型
• 允许避免冗长的PRId64/PRIu64

（我很清楚Visual C++从2005年起才支持%lld/%llu）
但是这个解决方案的可移植性如何可以通过对以下问题的回答来表达。

sizeof(long long) != 8的体系结构/ABI是什么？

如果你不能提供任何最新的/现代的，那么就继续使用旧的，但前提是它们仍然在使用。