X-Recipient:	archive-cygwin AT delorie DOT com
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
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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;
	s=default; bh=mPrdvSaGfW1CGNdfJr8h0jqiInE=; b=fENzcKaIeOZxC/lMp
	Ge15StS6i1enZqBbZxebczQhxcpsRs8rjVs/40r7EtQzyYnvv5wiR1h4ksPKSns3
	5l6J0RJ7/BlUhnHYKssC2ePCEqVOPYANSGd6sw6teq4AVQ7z+cHTk4zAbC/zk2Gx
	DZHkXliHaaWWwZy7pI4bzfNgZc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	limerock04.mail.cornell.edu
X-CornellRouted:	This message has been Routed already.
Message-ID:	<54F065A0.9030608@cornell.edu>
Date:	Fri, 27 Feb 2015 07:40:00 -0500
From:	Ken Brown <kbrown AT cornell DOT 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 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>
In-Reply-To:	<20150227084311.GF11124@calimero.vinschen.de>
X-IsSubscribed:	yes

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

- Raw text -