DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type; q=dns; s=default; b=l6oKSi
	/LSucXY884IXK/RE8xrj7j4PWSdpRFAfkNdl1sRgmBNuxsv70eS+XAe07VWcoQzr
	WRsp7qrn5O4MBx+6oTle585k34xdP+tlH2jGhpUdmr0Hd4Q6FRYPorqVysMs5Fbe
	0chGS943IqrGh7cm9ozmoEMnNQDtHp8wVDUW0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <54F098AA.9050503@redhat.com>
Date: Fri, 27 Feb 2015 09:17:46 -0700
From: Eric Blake <eblake AT redhat DOT com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: freopen/fread/popen bug
References: <54EFDEF4 DOT 4060308 AT cornell DOT edu> <20150227084311 DOT GF11124 AT calimero DOT vinschen DOT de> <54F065A0 DOT 9030608 AT cornell DOT edu>
In-Reply-To: <54F065A0.9030608@cornell.edu>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N3EvPPuj2x9FBv9qk07BfEfbDsdUEpuTI"

--N3EvPPuj2x9FBv9qk07BfEfbDsdUEpuTI
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/27/2015 05:40 AM, Ken Brown wrote:
>> Wrong expectations.  Keep in mind that the default read mode using
>> stdio functions is buffered.  So your fread fills the buffer in f.
>> The buffer is typically something like 1K or 4K.  If the file is
>> shorter than that, the file pointer will be set to EOF when calling
>> popen.  Try this before calling fread:
>>
>>    setvbuf(f, NULL, _IONBF, 0);
>=20
> In the actual code that I'm debugging (part of texinfo), I think that
> would create an unacceptable performance penalty for the child process.

How? Whether the parent reads buffered or unbuffered has no impact on
the child.

>=20
> What's really happening is that we need to peek at the first few bytes
> of f before deciding which program to call in popen.  After peeking,
> there's a call to fseek(f,0,0) before the popen, with the intention that
> the child receives a file pointer set to the beginning of the file.  (I
> left this out of my STC because it didn't affect the outcome.)  This
> apparently works on Linux.

Corinna is correct - you need to fflush() after the fseek() for it to
affect the underlying offset.  Or, just use read()/lseek() instead of
fread()/fseek() in the parent, to avoid stdio buffering altogether.
That way, you'll guarantee the offset the child process will inherit
without having to worry about flushing buffered state.

>=20
> But maybe the problem could be solved by doing a second freopen after
> peeking.

Only if freopen() is guaranteed to reset the file position to 0.  When
using freopen("file"), that is true; but when using freopen(NULL) (for
the side effect of changing text/binary mode), it is not guaranteed.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--N3EvPPuj2x9FBv9qk07BfEfbDsdUEpuTI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJU8JiqAAoJEKeha0olJ0Nq3eoH/3flm5C9lRHoo5S4IuChNijK
gxEuYt7p+NE+PFlTyLnQJ4zd1lo8L8DwR+2fZbjMriNA7Y+wXKfLeZznFeSTdJbX
s/cD3FVZy5ZniZW8C/ewXmxA1tAtIl+R49oZRqMrKBnTIsxFHxxKi/4N3fkYcTXB
rHjI6ZR+q+uYMvZ3JWydZw57erRwp1HiG2cqYfkCa8ZemVd5tZWPRBSSpLnB4TW/
hO9GhLBsx3T+1TYIP3Vco06g57us8xr9WScVrXOwEb95e4AlWCIj9ZzcZ1m8xL/B
Z4b8DwspQJAK2svvo6R1bPFG/78wJF/zVOVTBbOSprLS+zmC4fJGLBeS2nLtRuY=
=OnTu
-----END PGP SIGNATURE-----

--N3EvPPuj2x9FBv9qk07BfEfbDsdUEpuTI--