Mail Archives: djgpp/2009/04/04/09:00:51
> From: "Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
> Date: Sat, 4 Apr 2009 07:43:17 -0400
>
> "Eli Zaretskii" <eliz AT gnu DOT org> wrote in message
> news:83ljqgdchw DOT fsf AT gnu DOT org...
> > The main use-case for `freopen' is not to change the binary/text mode
> > of the file I/O,
>
> Is it? No offense intended, but that seems like half an implementation to
> me.
I said _main_ use-case, not _only_ use-case.
> freopen() is supposed to implement all functionality of fopen(), which
> includes opening the redirected-to-file as binary.
And it does, as long as you know the name of that file.
> > but to redirect I/O to _another_ file.
>
> Which, of course, could be the original file or character device acting like
> a file, i.e., CON since there is no C restriction preventing reopening the
> same file as itself but using a different mode.
Which worked for you as well, except CON is not an alias for standard
output unit, but a name of the terminal device. Calling `freopen'
for it sends output to the device, as you've discovered, not to the
(potentially redirected) standard output.
> Again, freopen() is
> supposed to implement all functionality of fopen(), which includes opening
> the redirected-to-file as binary. Therefore, if I reopen stdin as binary
> redirected to a file or character device which functions as stdin, e.g.,
> CON, and stdin isn't actually closed by the implementation of freopen(),
> since it doesn't have to be since freopen() ignores close errors, and isn't
> closed by DOS, then I'd expect a mode change.
There is no such thing as ``character device that functions as
stdin'', as far as DOS is considered. CON is just a file name, devoid
of any special meaning, for the part of DOS that deals with files.
(CON has special meaning only for the console device driver that
intercepts all file I/O and draws glyphs instead of writing data to
disk.) It is true that an interactive shell has its stdin connected
to CON, for obvious usability reasons, but that special function of
CON and stdin is something DOS does not care when it handles file I/O.
Moreover, each program running on the system has its own private stdin
handle connected to CON. Even they all reference the same device,
they are independent--which is a Good Thing, because this is how
program A can have its stdin in text mode while program B, which could
be a child process of A, can have its stdin in binary mode.
This all happens because DOS maintains handle-to-file association in a
table where each handle gets its own independent entry, even if it
refers to the same file/device as some other handle, and each process
gets its own entry even for standard handles 0, 1, and 2. Each entry
in the file handle table includes information about a file which is
open on that handle; when you close the handle, that information is
purged.
Redirection simply boils down to recording a different file as being
associated with a handle. But the associated file name is not
accessible by handle, at least not by documented DOS system calls.
> Does DOS actually close stdin, stdout, stderr, when one attempts to close
> them?...
Yes, certainly. Again, there's no special meaning DOS (or any other
OS, btw) assigns to these handles. Since their associated files or
devices are per process, there cannot be any harm in actually closing
them, except for the process on whose behalf they are closed, because
neither other processes nor the system itself are affected.
> > Sorry, I'm not following: how would ignoring close errors help in the
> > matter at hand, or is relevant to what we are discussing?
> >
>
> If ignoring close errors is legitimate, then there is no need to attempt to
> close stdin, stdout, or stderr.
As I explained, if you don't do that, you will leak descriptors and/or
get complaints from users whose programs don't need the 3 standard
ones and close them because they want to open all of the 255 available
handles to data files.
Also, if you don't close a handle, DOS does not flush its buffers, so
you can end up with unsaved data when users expect it to be safely on
disk, since they've closed the file.
- Raw text -