Re: [PATCH 0/4] Cross compiling sharutils

Filipe Brandenburger <[email protected]> Wed, 20 May 2015 21:40:16 -0700
Newsgroups gmane.comp.gnu.utils.bugs
Message-ID <CADU+-uDi5MvKZc=V5UQVkHfe7WjkT6AWjUzQDOT0dummUQZyFw@mail.gmail.com>
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...

Looking at the cygwin popen implementation (assuming I have the right
one), it doesn't really look like they look for a 'b' and handle that
any differently:

https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/posix/popen.c;h=faf72b6e380a8f74cc6af590a540b9fe292aab28;hb=HEAD#l120

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

In any case, I think it makes sense to check for O_BINARY and use the
FOPEN_{READ,WRITE}_BINARY defines. They don't really hurt... So I'll
send you a patch for that anyways.

Just doing a few more tests, will send you as soon as I'm confident it's good.

Cheers,
Filipe