X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=0.5 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,RCVD_IN_SORBS_WEB,SPF_HELO_PASS
X-Spam-Check-By:	sourceware.org
From:	"James Johnston" <JamesJ AT motionview3d DOT com>
To:	<cygwin AT cygwin DOT com>
References:	<CAHxe11=J=cJnwWcRnA1Pi9CmezWw+z04-b5k4trVmE3mVbiH7A AT mail DOT gmail DOT com> <CAHxe11=DBVftZ15xCLjnaEFYVESqggezJtx2EJNK2ZTUrMUNdQ AT mail DOT gmail DOT com> <00e101cd1f09$83405310$89c0f930$@motionview3d.com> <CAHxe11=ixmncGgNby3+RZspVQT6DxnFuTbCgH4si=yRk1EhmyQ AT mail DOT gmail DOT com>
In-Reply-To:	<CAHxe11=ixmncGgNby3+RZspVQT6DxnFuTbCgH4si=yRk1EhmyQ@mail.gmail.com>
Subject:	RE: 1.7.10->1.7.13 : output from .NET programs does not get through pipeline to a visual c++ program
Date:	Tue, 24 Apr 2012 14:31:11 -0000
Message-ID:	<016601cd2226$e692bb90$b3b832b0$@motionview3d.com>
MIME-Version:	1.0
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

> -----Original Message-----
> Sent: Tuesday, April 24, 2012 12:38
> Subject: Re: 1.7.10->1.7.13 : output from .NET programs does not get
through
> pipeline to a visual c++ program
> 
> >>> begin readin.cxx
> #include <windows.h>
> 
> int
> main(int argc, char* argv[])
> {
>     static_cast<void>(argc);
>     static_cast<void>(argv);
> 
>     HANDLE hi = GetStdHandle(STD_INPUT_HANDLE);
>     HANDLE ho = GetStdHandle(STD_OUTPUT_HANDLE);
> 
>     char buf[1024];
>     DWORD read, written;
>     ReadFile(hi, buf, 1024, &read, NULL);
>     WriteFile(ho, buf, read, &written, NULL);
> 
>     return EXIT_SUCCESS;
> }
> >>> end readin.cxx

What Corinna said... your problem is that you don't have a loop.  The reason
your program sometimes works and sometimes not is that sometimes the
execution of readin is delayed long enough such that you get all the data
buffered in the STD_INPUT_HANDLE pipe, and your program seems to work.
Other times, all you might get is only the null write, or only the "hello"
but not the "world".  That's because your consoleout program hasn't actually
written all its data yet - so ReadFile is only going to send you what it
knows and has buffered - it figures a partial response is better than
waiting (important for a network protocol or other device where the next
bytes could be a long time before they arrive, if ever!).  It's just random
luck, subject to the whims of the operating system scheduler.

In general, one must remember that when reading from a stream or file, the
read may be incomplete - not all data may yet be received, so the function
just returns what is buffered.  It is necessary to loop until either
end-of-file is reached, or a special terminating character or sequence is
reached, depending on the file format, network protocol, etc. (e.g. a
newline).  In your case, you'd loop until end-of-file is reached, which is
just what the built-in utilities like cat, grep, etc. do.

Sometimes, depending on the stream class / file API being used, you have to
write in a loop too - for example, WriteFile returns a parameter indicating
how many bytes were actually written; you would need to loop until all bytes
have actually been written.  It's possible that the underlying device just
isn't ready to handle all the data you are providing, so it will only bite
off an appropriately-sized chunk from what you provided.  (Other APIs, such
as .NET's Stream class, will block until all bytes have been written.)

I mention these things because I see too much code where programmers assume
just a single read or write covers what they need and it happens to work on
their computer - never mind that it would break on 5% of customer
computers/networks!  (Cleaning up things like that is not an enjoyable use
of time...)

James


--
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

- Raw text -