Mail Archives: djgpp/2009/04/04/03:57:45
> From: "Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
> 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.
- Raw text -