c语言数据类型占用字节_不同编译器与平台下的sizeof结果差异

sizeof(int)在windows和linux下通常均为4字节，由编译器实现决定而非操作系统；易混淆的是long：windows为4字节，linux x86_64为8字节。

sizeof(int) 在 Windows 和 Linux 下为什么不一样

它不一定不一样——int 的大小由编译器实现决定，不是操作系统直接规定的。主流 x86_64 平台下，GCC、Clang、MSVC 都把 int 定为 4 字节，和 Win/Linux 无关。真正容易混淆的是 long：在 Windows（MSVC 或 MinGW）上是 4 字节，而在 Linux（GCC）x86_64 下是 8 字节。

常见错误现象：printf("%ld", some_long_value) 在 Windows 上跑崩，或读出乱码——因为 %ld 期望 8 字节，但实际传入的是 4 字节的 long（MSVC）。

• 用 sizeof(long) 实测，别靠记忆或文档猜
• 跨平台代码中，优先用 int32_t / int64_t 替代 int / long
• Windows 上 MSVC 的 LLP64 模型（long long 是 8 字节，long 是 4 字节），Linux 上 LP64 模型（long 和 pointer 都是 8 字节）

char * 和 void * 的 sizeof 结果为什么总一样

因为它们都是指针类型，而指针大小只取决于地址空间宽度，和指向什么类型无关。在 64 位编译环境下，sizeof(char*)、sizeof(void*)、sizeof(int*) 全是 8；32 位下全是 4。

容易踩的坑：char buf[10]; sizeof(buf) 是 10，但 char *p = buf; sizeof(p) 是 8（或 4）——初学者常误以为“p 指向数组，所以大小还是 10”。

立即学习“C语言免费学习笔记（深入）”；

• 数组名在 sizeof 中不退化为指针，但传参给函数后就退化了
• void* 不能直接算术运算（p++ 非法），但 sizeof 对它完全合法
• 结构体里嵌套指针字段时，sizeof 只算指针本身，不算它指向的内容

结构体 sizeof 结果比成员字节和还大

这是内存对齐（alignment）导致的填充（padding）。编译器会在成员之间或末尾插入空白字节，让每个成员起始地址满足其对齐要求（通常是自身大小的整数倍）。

典型错误：用 memcpy 把结构体当二进制块发网络，对方平台结构体布局不同就解析错——尤其涉及 bool、char 和 int 混排时，填充位置可能不同。

• 用 _Pragma("pack(1)") 或 __attribute__((packed)) 强制紧凑布局，但会降低访问性能
• 检查对齐：用 _Alignof(type)（C11）或 alignof（C++）看类型要求
• 结构体最后一个成员之后可能还有填充，所以 sizeof(Struct foo) 不一定等于各成员 sizeof 之和

Float 和 double 的 sizeof 在所有平台都固定吗

sizeof(float) 几乎总是 4，sizeof(double) 几乎总是 8——这是 IEEE 754 单/双精度格式事实上的实现标准，GCC、Clang、MSVC 全部遵守。但严格来说，C 标准只要求 sizeof(float) ，没硬性规定字节数。

真正危险的是 long double：x86_64 Linux GCC 默认用 80 位扩展精度（sizeof(long double) == 16，含填充），而 MSVC 直接等价于 double（sizeof == 8）。

• 不用 long double 做跨平台序列化或 ABI 兼容接口
• 浮点数比较别用 ==，哪怕 sizeof 相同，二进制表示也可能因编译器优化路径不同而微异
• FLT_EVAL_METHOD 宏会影响中间计算精度，和 sizeof 无关，但会让相同代码在不同平台产生不同结果

对齐方式、指针模型、填充规则——这些才是 sizeof 差异背后真正要盯住的东西，而不是死记某个类型的字节数。