X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Date: Sat, 04 Apr 2009 16:58:23 +0300 From: Eli Zaretskii Subject: Re: setmode In-reply-to: X-012-Sender: halo1 AT inter DOT net DOT il To: djgpp AT delorie DOT com Message-id: <83bprccygw.fsf@gnu.org> References: <83ljqgdchw DOT fsf AT gnu DOT org> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Rod Pemberton" > Date: Sat, 4 Apr 2009 07:43:17 -0400 > > "Eli Zaretskii" 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.