Mail Archives: djgpp/2002/07/09/11:13:23
[Please keep the discussion on the mailing list.]
On Tue, 9 Jul 2002, Alex wrote:
> Strange thing happens though. At start-up the program normally outputs
> to the COM3 the following data:
>
> POWER UP TIME <time> DATE <date>
> REMOTE MODE IDLE <time>
>
> If something sent to stderr at this point, the program only gets to
> print this data partially, even though it sends the whole chunk to COM3 at
> once not by single character.
I suspect that this output is buffered by your program (does it use
printf to do that?), so what you see is that only part of the buffered
output is printed.
> So, it looks like redir intervenes with its output
> to COM3 at this moment and shuts down any further access to COM3 for the
> main program.
As I told earlier, redir cannot intervene: it's dormant at this point.
All redir does is invoke your program with stderr redirected to the COM3
port. After that, it's your program which sends the data through stderr
to COM3, not redir.
In other words, what happens is that once your program prints something
through stderr to COM3, COM3 is preempted by stderr and the data you
print through the other file descriptor never gets to the printer.
Does adding fflush to the place where you print data to the printer
solve the problem?
> > Finally, do you really need `redir' at all? Why can't you redirect
> > stderr to COM3 from within your application? You do have the sources,
> > right?
> Yes, that's correct, except one thing - I want redir to capture the
> crash dump in case the application goes down and send it to the printer.
If you redirect stderr to COM3 from within the application, the crash
dump will go to COM3 as well. The code which prints the crash dump
simply writes file handle 2, it doesn't care where is that handle
connected.
- Raw text -