On Thu, Apr 26, 2012 at 09:18:27PM -0000, James Johnston wrote:
>========== SenderC.c: Sender program in Visual C++ 2008 ==========
>
>#include <windows.h>
>int main() {
> char * test = "Hello world!\n";
> DWORD written;
> HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE); /* Get standard output
>file handle */
> Sleep(1000); /* wait for pipes to set up and for receiving app to
>block on first ReadFile call */
> WriteFile(h, test, 0, &written, NULL); /* do null write */
> Sleep(1000); /* wait for receiving app to get the null write */
> WriteFile(h, test, lstrlenA(test), &written, NULL); /* print hello
>message */
> return 0;
>}
>
>========== ReceiverCPP.cpp: Receiver program in Visual C++ 2008 that
>demonstrates bug in VC++ 2008 runtime / STL ==========
>
>#include <iostream>
>#include <string>
>using namespace std;
>int main() {
> /* you have to use a retry loop, for exact same reasons given for C#
>receiver program:
> there is no way to tell difference between end-of-file and null
>write. */
> for (int i = 0; i < 10; i++) {
> string str;
> /* BUG: cin will indicate end-of-file on a null write. */
> getline(cin, str);
> if (cin.eof()) {
> cout << "Got end-of-file" << endl;
> } else {
> cout << "Got line " << str << endl;
> }
> cin.clear(); /* future getline calls will always immediately
>fail without attempting another read unless we clear EOF/fail flags */
> }
> return 0;
>}
>
>========== Test results ==========
>
>The test programs are designed so that they can be run in any combination
>from the command prompt. The output from a sender is piped to the input of
>a receiver. Each combination delivers identical output to the other
>combinations:
>
> * ./SenderCS | ./ReceiverCS
> * ./SenderCS | ./ReceiverCPP
> * ./SenderC | ./ReceiverCS
> * ./SenderC | ./ReceiverCPP
>
>Output from Cygwin will always be:
>
>Got end-of-file
>Got line Hello world!
>Got end-of-file
>Got end-of-file
><snip>
Nope, it won't always be that because I get what's expected. I built
the C++ files using mingw g++. Although I actually expected the reader
to honor the null byte, it did not. Perhaps you are using a different
version of Windows than I am or a different runtime.
What you are seeing may be because Cygwin was changed to use
message-type pipes a couple of revisions ago. This is not going to
change. The change was adopted to fix a problem with Cygwin programs
and those are obviously our #1 priority.
>This is wrong, because the program received end-of-file before it was
>actually at the end of the input stream, due to the bug in its runtime's
>handling of return values from ReadFile API. I did not do any tests using
>standard error, but I assume Cygwin redirects standard error in the same way
>it redirects standard output, in which case it would have the same problem.
>
>[moved]
>
>I think a workable fix would be for Cygwin not to pass through null writes
>it receives on an output/error pipe. For example, somewhere in Cygwin I
>assume there is a loop that calls ReadFile to read the redirected standard
>output from the first program, and then calls WriteFile to send this output
>to the second program's standard input. If the call to WriteFile was
>skipped if it would write zero bytes (i.e. so Cygwin doesn't do null writes
>itself), I think it would fix the problem and work around all these buggy
>runtimes.
There's no way that Cygwin could know to "skip" a call to WriteFile().
Cygwin doesn't interpose itself in the middle of a pipe. That would be
truly disastrous. If it somehow looked at every pipe read/write rather
than just allowing I/O to flow from one end to the other, the mailing
list would be even more filled with people complaining that Cygwin is
slow.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
