www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2009/04/04/06:45:14

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
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: <gr7gu5$aou$1@aioe.org>
References: <gr3fv1$s9f$1 AT aioe DOT org> <uk561j05t DOT fsf AT gnu DOT org> <gr72bt$tjk$1 AT aioe DOT org> <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" <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.  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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019