C语言以写入模式打开的文件为何在Windows可读取，Linux结果不同？

这一现象的核心是未定义行为下不同平台C标准库实现的兼容策略不同，具体逻辑如下：

1. 首先明确C标准的约束 #

根据ISO C标准规定：

• fopen使用"w"模式打开文件时，流仅支持写操作，直接调用fread属于未定义行为，标准没有规定这类操作的返回结果，不同平台的实现差异完全符合规范。
• 即便是使用支持读写的"+"后缀模式（如"w+"），写操作和读操作之间也必须调用fflush、fseek、fsetpos或rewind来同步流状态，否则行为同样是未定义的。

2. Windows平台（MinGW/msvcrt）的实现逻辑 #

你在Windows上用MinGW g++编译的程序默认会链接微软的msvcrt标准库，该库对只写模式的读操作做了兼容扩展：

• 不会直接拦截只写流的读请求，所以你调用fread不会直接返回0。
• 你写完11字节数据后没有做缓存同步操作，数据还存在用户态的stdio缓冲区中，没有落到内核文件缓存，同时文件指针已经移动到偏移量11的位置，这时候读操作会从当前偏移往后读取，你测试时的返回值5大概率是读取到了原有文件在偏移11后的5字节内容，缓冲区原有内容被覆盖所以打印为空。
• 你添加fflush后会把用户态缓冲区的内容刷到内核，添加fseek会同步用户态和内核的文件偏移并触发缓存刷写，这时候流状态符合标准预期，结果就和Linux一致。

3. Linux平台（glibc）的实现逻辑 #

glibc严格遵循C标准约束：

• 只写模式打开的流不响应读请求，fread直接返回0，不会修改传入的缓冲区，所以你原先写入buf的hello world没有被覆盖，打印结果和写入内容一致。

• 有同时读写文件的需求时，必须使用带"+"后缀的打开模式（如"w+"），不要在只读/只写模式下执行相反的IO操作。
• 读写操作切换时，严格按照标准要求调用fflush或者文件定位函数同步流状态，保证代码的跨平台兼容性。

内容的提问来源于stack exchange，提问作者WSMao