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:content-transfer-encoding;
	 q=dns; s=default; b=sLEVcht0DhnXLi2hBrkatSFKRbxI951Z5Xy682y7fhm
	BZVYzyeBsRGBTHJR5oby+bCwVpVEjF+/+nBCRjfp3Mi/piiqiwba1GIOJ+hS0Z+c
	+MLLRFK5areJlyhXEVyHjFGP4bG5TldaFR2spTAyZABnTITBkOWHsYjB1p5zhvTQ
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <54F065A0.9030608@cornell.edu>
Date: Fri, 27 Feb 2015 07:40:00 -0500
From: Ken Brown <kbrown@cornell.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: freopen/fread/popen bug
References: <54EFDEF4.4060308@cornell.edu> <20150227084311.GF11124@calimero.vinschen.de>
In-Reply-To: <20150227084311.GF11124@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2/27/2015 3:43 AM, Corinna Vinschen wrote:
> On Feb 26 22:05, Ken Brown wrote:
>> I'm not sure exactly where the bug is, but here's what happens (STC at the end):
>>
>> 1. I use freopen to open a file "foo" and associate it with stdin.
>>
>> 2. I use fread to read a byte from foo.
>>
>> 3. I call popen, expecting the child process to have foo as its stdin, with
>> the file-position indicator pointing to the second byte.  But instead the
>> child sees an empty stdin.
>>
>> If I omit step 2, the child process does indeed have foo as its stdin.  Are
>> my expectations wrong, or is this a bug?
>
> 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);

In the actual code that I'm debugging (part of texinfo), I think that would 
create an unacceptable performance penalty for the child process.

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.

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

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple