В чем смысл fclose()?

Длительному процессу (например, базе данных или веб-браузеру) может потребоваться открыть много файлов за время своего существования; хранение неиспользуемых файлов открытыми приводит к трате ресурсов и потенциально блокирует использование файлов другими процессами.

Кроме того, fclose очищает буфер пользовательского пространства, который часто используется при записи в файлы для повышения производительности; если процесс завершается без очистки этого буфера (с fflush/fclose), данные, все еще находящиеся в буфере, будут потеряны.

Большинство современных операционных систем также восстанавливают память, которую вы malloc() выделили, но использование free(), когда это уместно, по-прежнему является хорошей практикой. Дело в том, что, как только вам больше не нужен ресурс, вы должны отказаться от него, чтобы система могла переназначить любые резервные ресурсы, которые были освобождены, для использования другими приложениями (обычно это память). Также существуют ограничения на количество файловых дескрипторов, которые вы можете держать открытыми одновременно.

Кроме того, есть дополнительные соображения в случае open() и его друзей, в частности, по умолчанию дескрипторы открытых файлов наследуются через поток и fork() границы процесса. Это означает, что если вы не close() файловых дескрипторов, вы можете обнаружить, что дочерний процесс может получить доступ к файлам, открытым родительским процессом. Обычно это нежелательно, это тривиальная дыра в безопасности, если вы хотите, чтобы привилегированный родительский процесс порождал подчиненный процесс с меньшими привилегиями.

Кроме того, семантика unlink() и друзей заключается в том, что содержимое файла «удаляется» только после того, как последний открытый файловый дескриптор файла становится close(), поэтому еще раз: если вы держите файлы открытыми дольше, чем это строго необходимо, вы вызываете неоптимальное поведение в общая система.

Наконец, в случае сокетов close() также соответствует отключению от удаленного партнера.