X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: setmode Date: Sat, 4 Apr 2009 07:43:17 -0400 Organization: Aioe.org NNTP Server Lines: 46 Message-ID: References: <83ljqgdchw DOT fsf AT gnu DOT org> NNTP-Posting-Host: pldq+kT97bAAp/ObDwnZyQ.user.aioe.org X-Complaints-To: abuse AT aioe DOT org NNTP-Posting-Date: Sat, 4 Apr 2009 11:39:49 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 X-Notice: Filtered by postfilter v. 0.7.7 X-Newsreader: Microsoft Outlook Express 6.00.2800.1933 Cancel-Lock: sha1:zK/+75OePrXPjWZlQ3we0W9GdUg= X-Priority: 3 X-MSMail-Priority: Normal To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "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. freopen() is supposed to implement all functionality of fopen(), which includes opening the redirected-to-file as binary. > 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. 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. > If it doesn't > close the original one, it will either leak resources or unnecessarily > hit the max available handle limit (or both). Does DOS actually close stdin, stdout, stderr, when one attempts to close them?... My gut says no. In which case, all DJGPP is doing is forfeiting OS redirection when it doesn't have to. > > If correct, that would allow file close errors in freopen() by > > design or intentionally for stdin, stdout, stderr. > > 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. There is only a need to attempt to close handles other than those three. In which case, freopen() with a "wb" on stdin could also setmode O_BINARY on stdin without loosing redirection on stdin since stdin was never actually closed. Rod Pemberton