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 11:55: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: <83ljqgdchw.fsf@gnu.org> References: 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 03:34:38 -0400 > > > redirection is maintained by the OS > > Time for me to try to find out more about this, I guess... Of course, the > question becomes: Why would freopen() close or attempt to close stdin, > stdout, stderr? The main use-case for `freopen' is not to change the binary/text mode of the file I/O, but to redirect I/O to _another_ file. If it doesn't close the original one, it will either leak resources or unnecessarily hit the max available handle limit (or both). > I haven't looked at what the C spec. says here, but I'm > fairly sure Harbison & Steele 3rd ed. says file closing errors in freopen() > are ignored. That's what the DJGPP library implementation of `freopen' does, please take a look at the sources. > 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? > > Why isn't using `setmode' good enough? That's what all applications > > that need this do. > > It is. It works. I use it enough. But, I was really wanting ANSI C only > in this case. ANSI C leaves the semantics of the whole binary/text issue as implementation defined. > > since switching the console device to binary has > > some unpleasant side effects in DJGPP: e.g., SIGINT is not produced by > > Ctrl-C. > > Interesting... Does this block Ctrl-C better than signal() to SIG_IGN on > SIGINT, SIGQUIT, SIGABRT inconjunction with setcbrk()? Yes, better: using SIG_IGN does not prevent the entire chain of events triggered by Ctrl-C, whereby we reset the DJGPP application's data segment to the null page, cause the app to GP Fault when it touches any of its data, then catch the exception and just return without doing anything if we see that the signal handler is SIG_IGN. What `setmode' does when you set file descriptor 0 (stdin) to binary mode is call `__djgpp_set_ctrl_c', which prevents the above chain of events in the first place; instead, Ctrl-C is delivered to the application as a normal character. This is meant for applications that want to get all the raw input characters verbatim, and do any processing themselves. Emacs is one example. Note that with the latest libc, switching stdout to binary should not have this effect, but I'd still avoid that. > This came up a while > ago in comp.os.msdos.programmer. Unfortunately, it seems he never posted to > comp.os.msdos.djgpp. My solution apparently didn't work for him. Later, I > found out that it worked well for some of my applications, but it doesn't > work well for every application... Some still leak large numbers of > ctrl-c's. > http://groups.google.com/group/comp.os.msdos.programmer/browse_thread/thread/98a6c66a3aa291ae/c83696ed4bae0310?hl=en Using `__djgpp_set_ctrl_c' is the right solution to that problem.