Re: [PATCH 0/4] Cross compiling sharutils

> Date: Wed, 20 May 2015 21:40:16 -0700
> From: Filipe Brandenburger <[email protected]>
> Cc: Eli Zaretskii <[email protected]>, Eric Blake <[email protected]>, [email protected]
> 
> On Wed, May 20, 2015 at 9:05 PM, Filipe Brandenburger
> <[email protected]> wrote:
> > I got my hands on a Windows instance and installed cygwin on it, so
> > I'm currently running cygwin tests to ensure there's no regression.
> 
> Hmmm... So I checked cygwin and I built a version of the unmodified
> tarball and then another one where I just changed the freadonly_binary
> to "r" in the popen call.
> 
> I tried shar -C gzip/xz/bzip2 on many files, unpacked them by running
> the shar script and compared them with the original, but I didn't
> really manage to reproduce the issue by which popen with a simple "r"
> corrupted the files...

It was I who added the binary mode to some popen calls in Sharutils.
I did that when I worked on the MinGW port of Sharutils.  The reason
is simple: you _must_ read output from a compressor in binary mode,
because what the compressor outputs is binary data, not text.  If you
read it in text mode, the read will stop on the first ^Z character,
and it will strip CR characters from the data.  (I'm guessing that the
former doesn't happen in Cygwin, so you don't see problems because
your examples, by sheer luck, didn't have CR characters in the
compressed data, or maybe didn't have them before an LF character.)

> So I'm really at a loss at why this code was even there, as I can't
> really think of another platform that would conceivably handle
> popen("rb") different from popen("r") if cygwin doesn't...

See above: all Windows platforms do.