直接使用I/O缓冲区是否安全？C与C++场景下的合规性问询

问题描述 #

我在Ubuntu系统中运行一段C++代码，通过setvbuf将自定义data数组设置为inFile的全缓冲I/O缓冲区，调用fgetc后直接读取data数组并写入outFile，代码运行正常，但不确定该操作是否合规。cppreference指出，成功调用setvbuf后数组内容不确定，直接使用属于未定义行为，但setvbuf的man手册未提及该限制。此外，我想了解该问题在C语言场景下是否有不同结论。

相关代码 #

C++代码 #

if (setvbuf(inFile, data, _IOFBF, std::size(data)))
{
    throw std::runtime_error("can't set buffering mode");
}

fgetc(fileDesc);
// After getc the bytes from file are presented in data array
fwrite(data, std::size(data), 1, outFile);

C语言代码 #

char data[BUFFER_SIZE];

if (setvbuf(inFile, data, _IOFBF, sizeof data))
{
    perror("can't set buffering mode");
    return -1;
}

fgetc(fileDesc);
// After getc the bytes from file are presented in data array
fwrite(data, sizeof data, 1, outFile);

解答 #

无论C还是C++标准，直接访问setvbuf设置的自定义缓冲区都属于未定义行为，和你使用的Ubuntu系统无关：

• 标准层面：C和C++标准均明确规定，程序不得直接访问标准I/O库管理的缓冲区内容。setvbuf仅允许你向库提供一块内存用于缓冲，但缓冲区的内部布局、数据存储逻辑、填充/刷新时机都是标准库的实现细节，没有任何标准保证你能从中读取有效数据。cppreference的表述符合标准要求，而man手册仅描述函数用法，未覆盖标准中的未定义行为限制。
• 运行正常的原因：这是Ubuntu所使用的glibc库的特定实现巧合——在全缓冲模式下调用fgetc会填充缓冲区，数据确实会存入你提供的数组，但这属于实现细节，更换编译器、标准库（如musl libc）或编译选项后，该行为可能发生变化，甚至引发程序崩溃。
• 合规实现方式：若需获取读取的原始数据，应使用fread直接将数据读入自定义缓冲区，而非绕过标准库接口访问其内部缓冲。例如将fgetc替换为fread(data, 1, std::size(data), inFile)（C++）或fread(data, 1, sizeof data, inFile)（C），这样数据直接存入你的数组，行为完全符合标准。

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