0 
$ cd glibc-2.23
$ grep -ErI --include='*.c' '= *f?put([cs]|char)\>' |wc -l
1
$ grep -ErI --include='*.c' '[^= ] *f?put([cs]|char)\>' |wc -l
1764

$ man putc
...
RETURN VALUE
   fputc(), putc() and putchar() return the character written
   as an unsigned char cast to an int or EOF on error.

也许这是“不太可能”，例如在一系列putchar s 中，一个或两个不明显地失败，而前面和后面的确实成功了？
或者，至少在 99.9999% 的实现中，它们可能根本就没有“return suchandsuch”语句？
或者，连续错误检查，在每个字节之后（在 putchar、putc、fputc 的情况下），可能会导致太大的性能下降？

4

2 回答 2

1

忽略函数的返回值是软件中许多难以发现的错误的根源。您关于“没有人”检查返回值的说法是不正确的。高可靠性软件系统会检查返回值。

于 2016-12-08T15:38:30.473 回答
0

由于几个原因，这些经常被忽略。首先，对于大多数系统而言，它们出现问题的可能性非常小，以至于大多数人根本不在乎。

其次，因为如果它们确实失败了，那么无论如何您通常都无能为力——如果操作系统进入写入文件失败的状态，通常的反应，例如向用户显示消息和/或记录该错误也可能很容易失败。

最后，在大多数情况下，您可以将问题简化很多：执行您的 I/O，然后仅对是否fclose成功进行错误检查。如果文件已进入失败状态，您可能会fclose失败，因此较早捕获错误（当您执行 I/O 时）通常只是一种优化——您可以通过仅检查来检测相同的问题fclose，尽管您可能在您可能检测到问题之后，浪费一些时间在徒劳地尝试写入文件。

不过，即使检查来自的回报fclose也相当不寻常。你仍然有上面提到的同样的问题：如果系统已经失败到了失败的地步，那么你对失败做出反应的大多数尝试也很有可能也会失败。

尽管如此，仍有一些情况是有意义的。例如，考虑将文件从一个地方移动到另一个地方（例如，通过网络）。您想在删除源文件之前检查是否已成功将数据写入目标。在这种情况下，检查返回fclose是一种相当简单的方法，可以减少破坏用户文件的机会，以防复制尝试失败。

于 2016-12-08T18:01:40.263 回答