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