当然，大多数情况的直接答案是“是”，我坚信过程应该正确清理它已分配的任何资源，但我的情况是一个长时间运行的系统守护程序，它在启动时打开固定数量的文件描述符，并在退出之前将它们全部关闭。
这是一个嵌入式平台，我正在努力使代码尽可能紧凑，同时不引入任何不良风格。但是，由于文件描述符无论如何都会在退出之前关闭，这个文件描述符清理代码是否可以用于任何目的？你总是关闭所有文件描述符吗？
答案 0 :(得分：13)
使用它们时关闭文件描述符可使代码更易于重用，更易于扩展。这听起来像是一个你有正当理由让它们自动关闭的情况。
答案 1 :(得分：6)
在嵌入式平台的美丽世界中，很难说会发生什么。但是，如果我在你的情况下，我只是手动测试以查看文件ID是否真的被释放..而且，如果空间很重要，也许你可以在其他地方记录这个事实。
答案 2 :(得分：6)
是的，关闭你的文件描述符并释放所有堆内存，即使你知道操作系统会清理它 - 这样，当你运行valgrind或类似的工具时，你不会得到很多噪音结果，您可以轻松识别“合法”的fd泄漏。
答案 3 :(得分：5)
关于将文件描述符关闭到自动清理的关键问题，关键是你关心你写入文件描述符的任何数据，以及你是否合理地处理了写。
write（）不需要阻塞（取决于它首先是如何打开（））并等待数据成功提交，因此有些情况下close会失败，因为底层子系统无法提交挂起写入，因此关闭退出失败并将errno设置为EIO，并且根据您刚写的内容，您可能会或可能不想采取一些纠正措施。
不可否认，这是一个极端情况，您真正关心数据一致性，即DBMS类型的应用程序或报告备份的成功/失败。在许多（大多数？）情况下，它并不重要，并且你可以在close（）处理清理/退出时保持原状。
答案 4 :(得分：4)
man 3退出：
....
All open stdio(3) streams are flushed and closed. Files created by tmpfile(3) are removed.
所以我相信离开main有效地调用具有main的返回值的exit函数。虽然我认为这是不好的风格。就个人而言，我总是明确地释放/关闭所有获得的资源。