29

如果由于某种原因，我在我的程序中发现了一个致命的情况，并且我想以错误代码退出。有时，致命错误的上下文超出了其他文件描述符的范围。关闭这些文件描述符是一个好习惯吗？据我所知，这些文件会在进程终止时自动关闭。

4

6 回答 6

17

文件会自动关闭，但这是一个好习惯。

请参阅此示例中的 valgrind

david@debian:~$ cat demo.c
#include <stdio.h>

int main(void)
{
    FILE *f;

    f = fopen("demo.c", "r");
    return 0;
}
david@debian:~$ valgrind ./demo
==3959== Memcheck, a memory error detector
==3959== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3959== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==3959== Command: ./demo
==3959== 
==3959== 
==3959== HEAP SUMMARY:
==3959==     in use at exit: 568 bytes in 1 blocks
==3959==   total heap usage: 1 allocs, 0 frees, 568 bytes allocated
==3959== 
==3959== LEAK SUMMARY:
==3959==    definitely lost: 0 bytes in 0 blocks
==3959==    indirectly lost: 0 bytes in 0 blocks
==3959==      possibly lost: 0 bytes in 0 blocks
==3959==    still reachable: 568 bytes in 1 blocks
==3959==         suppressed: 0 bytes in 0 blocks
==3959== Rerun with --leak-check=full to see details of leaked memory
==3959== 
==3959== For counts of detected and suppressed errors, rerun with: -v
==3959== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

如您所见，它引发了内存泄漏

在某些情况下，您可以使用atexit()：

#include <stdio.h>
#include <stdlib.h>

static FILE *f;

static void free_all(void)
{
    fclose(f);
}

static int check(void)
{
    return 0;
}

int main(void)
{
    atexit(free_all);
    f = fopen("demo.c", "r");
    if (!check()) exit(EXIT_FAILURE);
    /* more code */
    return 0;
}
于 2013-03-06T12:06:27.480 回答
16

POSIX 编程的经典指南“UNIX 环境中的高级编程”指出：

当一个进程终止时，其所有打开的文件都会被内核自动关闭。许多程序利用了这一事实，并且不会明确关闭打开的文件。

您没有在问题中提到操作系统，但任何操作系统都应该出现这种行为。每当您的程序控制流交叉exit()或return来自main()它时，系统有责任在该过程之后进行清理。

操作系统实现中总是存在错误的危险。但是，另一方面，系统必须在进程终止时释放多个打开的文件描述符：可执行文件映像、堆栈、与进程关联的内核对象占用的内存。您无法从用户空间控制此行为，您只能依赖其按预期工作。那么，为什么程序员不能依赖fds 的自动关闭呢？

因此，保持fd开放的唯一问题可能是编程风格问题。而且，在使用stdio对象（即围绕系统提供的文件 i/o 构建的东西）的情况下，您可能会在 valgrinding 时（有点）获得迷失方向的警报。至于泄露系统资源的危险，应该没什么好担心的，除非你的操作系统实现真的有问题。

于 2013-03-06T13:09:54.103 回答
7

据我所知，这些文件会在进程终止时自动关闭。

不要依赖那个。从概念上讲，当进程终止时，释放分配的内存、关闭非标准文件描述符等是您的责任。当然，每个健全的操作系统（甚至 Windows）都会在您的进程之后清理，但这不是预期的。

于 2013-03-06T12:04:28.100 回答
3

是的。假设您的主程序现在是单独程序中的一个类。现在您刚刚描述了资源泄漏。通过依赖全局程序状态（即进程的状态）实质上违反了封装——不是你的模块，不是类，不是 ADT，不是线程，而是整个进程——处于关闭状态。

于 2013-03-06T12:06:48.227 回答
3

每个健全的操作系统（当然是任何形式的 Linux 或 Windows）都会在程序终止时关闭文件。如果您有一个非常简单的程序，那么您可能不需要在终止时关闭文件。但是，明确关闭文件仍然是一种很好的做法，原因如下：

  1. 如果您将其留给操作系统，您将无法控制文件关闭的顺序，这可能会导致一致性问题（例如在多文件数据库中）。

  2. 如果存在与关闭文件相关的错误（例如 I/O 错误、空间不足错误等），您将无法报告它们。

  3. 可能需要处理与文件锁定的交互。

  4. 关闭所有文件的例程可以同时处理程序需要的任何其他清理（例如，刷新缓冲区）

于 2017-05-02T08:43:33.143 回答
2

exit如果您的程序正常终止（即通过或返回） ，C 确实保证所有打开的文件都将被关闭main。但是，如果您的程序异常终止，例如由于使用 NULL 指针而被操作系统关闭，则由操作系统来关闭文件。因此，最好确保文件在不再需要时关闭，以防意外终止。

另一个原因是资源限制。大多数操作系统对打开的文件数量（以及许多其他内容）都有限制，因此最好在不再需要这些资源时立即返回它们。如果每个程序都无限期地打开所有文件，系统可能很快就会遇到问题。

于 2013-03-06T13:16:38.943 回答