Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)

Christopher Faylor
Fri Apr 27 16:28:00 GMT 2012

On Fri, Apr 27, 2012 at 02:26:13PM -0000, James Johnston wrote:
>>On Thu, Apr 26, 2012 at 08:17:18PM -0400, Christopher Faylor wrote:
>>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.
>As I stated, I did two demo programs using Visual C++ 2008 and .NET
>Framework 3.5.  I did not test mingw.

I did not say that you tested MinGW.  I was telling you what I tested.
However, as it turns out, I created the executable on Linux and my
environment still ended up creating a Cygwin binary.  Correctly
rebuilding with MinGW shows the same behavior you reported.  Sorry
for getting that wrong.

Btw, MinGW does not have its own runtime.

>This is on Windows 7 64-bit, fully up-to-date.  Perhaps your mingw
>runtime doesn't have this bug, in which case, good for them! But that
>doesn't change the fact that not many people use mingw in comparison to
>Visual C++ or .NET Framework 3.5.  And I'm not sure how you can
>complain that you can't reproduce it if you don't use similar tools to
>what was used to originally reproduce the issue.  (Did I really need to
>preface my phrase of "will always be" with conditions that you use
>Visual C++ / .NET Framework?  I thought it would be obvious, especially
>since I was referring to bugs in their runtimes...)

I wasn't "complaining" that I could not reproduce the problem.  I was
stating a fact.  And, again, to be clear, I was also not doubting that
you could demonstrate a behavior.  I can see it now too and I'm actually
kind of relieved to see that it matches my expectations.

Regardless of how many people use Visual C++ or .NET they are really not
our target audience.  It's nice when things work for people who don't
want to use UNIX tools but they are not our primary focus.  Fixing
problems for people who want to use non-Cygwin stuff is not something
that I find a high priority.

If you want to a fix for this problem then you'd be best off if you
supplied one yourself:

Maybe I'm in the minority but I find long-winded impassioned pleas
rather boring and off-putting.  So, continuing in this vein is not going
to be productive for you, at least as far as I'm concerned.


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list