This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Can't reliably redirect standard output from C# program in recent Cygwin

Just tried the DLL from the snapshot and both my programs work fine now. :)

I think I found what you refer to...  From ReadFile page:

"If the lpNumberOfBytesRead parameter is zero when ReadFile returns TRUE on
a pipe, the other end of the pipe called the WriteFile function with
nNumberOfBytesToWrite set to zero."

"When a synchronous read operation reaches the end of a file, ReadFile
returns TRUE and sets *lpNumberOfBytesRead to zero."

"If an anonymous pipe is being used and the write handle has been closed,
when ReadFile attempts to read using the pipe's corresponding read handle,
the function returns FALSE and GetLastError returns ERROR_BROKEN_PIPE."

So if I'm reading this right, if reading a file, I'd look for a successful
return and number of bytes read == 0?  But for a pipe, instead that
situation should be *ignored* and instead I should look for an
ERROR_BROKEN_PIPE to signify "end of file"?  Really?  That's tricky.  I
learned something new.  I'm not sure if it's really the best design on
Microsoft's part, because now you can't even easily write a generic "read
file until end-of-file" function since it would have to be special-cased for
pipes (and who knows what else).

I wonder why it worked sometimes but not other times (e.g. running "echo
`./HelloCPP | cat`" would sometimes work, sometimes not)?  With something
like this, I would think it would not work 100% of the time.

Best regards,

James Johnston

-----Original Message-----
Sent: Monday, March 12, 2012 22:02
Subject: Re: Can't reliably redirect standard output from C# program in
recent Cygwin

On Mon, Mar 12, 2012 at 05:28:17PM -0000, James Johnston wrote:
>Well, good call.  I shouldn't have jumped to conclusions.  Both my C++ 
>and C# examples still fail:

Not really a call.  It was obviously different failure.  The previous fix
wasn't even pipe related.

But, regardless, Corinna (who has more time these days to look into this
type of thing) found a damning piece of MSDN documentation which indicates
that a write of zero bytes to a pipe will cause a read of zero bytes on the
other end of the pipe.  So, a program which assumes that a zero byte read
means EOF, like most Linux programs, will stop processing when it sees the
zero bytes from ReadFile.

Corinna sent me a patch to fix the problem which I've mildly tweaked and
installed.  It's in the latest snapshot.


Problem reports:
Unsubscribe info:

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]