Then that would leave you pretty close to automatic dynamic storage
recycling, no ? ;_)

-------- Original Message --------
Subject: Re: close(file); always necessary??
From: Frank Heckenbach <>
Date: Tue, June 15, 2010 10:24 am
To: 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 Heckenbach,,, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8