samiam@moorecad.com wrote:

There are actually several places where the implementation choose to close a file. The first could be the procedure or function to which the file is local. Ie., if the file is permanently leaving scope, there is no reason not to close it. The second would be when the program exits, that is, the support library for the implementation can close the file. Lastly, as discussed, the OS can close the file(s) as part of the shutdown for the task/process.

In fact, GPC does the first, its runtime system does the second, and probably all current OSs do the latter, but as he worte, that's all relying on the implementation. Another compiler might not do the former two, and buffer data, so even though the OS closes the file, some data might be lost. So I agree, usually it's good practice to close all files opened for writing. (For read-only file access, and provided there are not so many files that a limit on the the number of files becomes relevant, I can hardly imagine a problem with not closing them, though ...)

For example, IP Pascal keeps a table of open files in the support library, and shuts them down automatically when the program exits as part of a general cleanup. It does not bother to try to close the files when they leave scope, which would involve things like trying to find and close arrays or structures containing files.

GPC even does that. It needs to traverse structures for initialization and finalization anyway (e.g., to set schema discriminant fields, or to initialize files to a known undefined state), so this part of the work was already done.

Frank