是否在两个不同的 fstream 未定义行为中打开相同的文件？

Question

这个recently asked question 提出了另一个有趣的问题，正如comments to one of its answers 中所讨论的那样。

总结一下：当随后尝试“同时”从两个流读取/向两个流写入数据时，OP 存在如下代码问题：

ifstream infile;
infile.open("accounts.txt");

ofstream outfile;
outfile.open("accounts.txt");

虽然问题本身已成功解决，但它提出了一个我无法找到权威答案的问题（我已经对 Stack Overflow 和更广泛的网络进行了一些相当广泛的搜索）。

非常清楚地说明了在调用已经与 文件 (cppreference) 关联的 流 的 open() 方法时会发生什么，但我当file 已经与（不同的）stream 相关联时（在本例中）会发生什么，无法找到答案。

如果流已经与文件相关联（即，它已经 open)，调用该函数失败。

我可以在这里看到几种可能的情况：

1. 第二次打开的调用将失败，任何尝试写入它的操作也将失败（但在引用的问题中不是）。
2. 第二个打开的调用将“覆盖”第一个，有效地关闭它（这可以解释上述代码中遇到的问题）。
3. 两个流都保持打开状态，但进入关于其内部文件指针和缓冲区的“相互破坏”匹配。
4. 我们进入了未定义（或实现定义）行为的领域。

请注意，由于第一个 open() 调用是由输入流进行的，因此操作系统不一定会像对输出流那样“锁定”文件。 p>

那么，有人对此有明确的答案吗？或者来自标准的引用（如果找不到更权威的，cppreference 将是“可接受的”）？

Answer 1

basic_filebuf::open（以及所有依赖它的东西，比如fstream::open）没有说明在这种情况下会发生什么。文件系统可能允许，也可能不允许。

标准的意思是，如果文件成功打开，那么你就可以按照界面来玩了。如果它没有成功打开，那么就会出现错误。也就是说，该标准允许文件系统允许或禁止它，但它没有说明必须发生什么。该实现甚至可以随机禁止它。或者禁止您以任何方式打开任何文件。所有（理论上）都是有效的。

Answer 2

对我来说，这甚至超出了“实现定义”字段。根据底层文件系统或操作系统（某些操作系统禁止打开文件两次），相同的代码会有不同的行为。

Answer 3

没有。

标准没有讨论这种情况。

它甚至不受实现（您的编译器、标准库实现等）的管理。

流最终要求操作系统以所需的模式访问该文件，由操作系统决定当时是否应授予该访问权限。

一个简单的类比是您的程序通过网络对 Web 应用程序进行一些 API 调用。也许 Web 应用程序不允许每分钟调用超过 10 次，并且如果您尝试超过此次数，则会返回一些错误代码。但这并不意味着您的程序在这种情况下具有未定义的行为。

Answer 4

C 实现存在于许多不同的平台上，它们的底层文件系统可能会以不同的方式处理这些极端情况。如果标准强制要求任何特定的极端情况行为，那么该语言只能在文件系统以这种方式运行的平台上实用。相反，该标准将此类问题视为超出其管辖范围（即使用其自己的术语“未定义行为”）。这并不意味着目标操作系统提供有用保证的实现不应该在实际情况下对程序做出此类保证，但实现设计者被认为比委员会更了解如何最好地为他们的客户服务。

另一方面，实现不暴露底层操作系统行为有时可能会有所帮助。例如，在没有明显“追加”模式的操作系统上，但需要“打开以追加”的代码可以执行“打开现有文件以进行写入”，然后是“寻找文件结尾”，尝试打开两个流以追加到同一个文件可能会导致数据损坏，当一个流写入文件的一部分，而另一个流随后重写该相同部分时。对于检测到该条件的实现来注入自己的逻辑以确保数据的平滑合并或阻止第二个打开请求，这可能会有所帮助。取决于应用程序的目的，任何一种行动方案都可能更好，但是 - 如上所述 - 选择不在标准的管辖范围内。