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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=FG
	jqT+7XdFS26bAAyqIB7+HMMBcR4ntzy83VkytFjCwlSQ62cF1eKTXY6Vo6tmmnki
	dH6QTnakfELwIUHmiUPXLlQAc/Z2RgcacQ07F54St+XpBa64YX0xqJP2RzV6SUUP
	cg8Wb038bz3WBebcWk1YnrAcwXxlyzmIeGmzKXESI=
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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=K5SirzmK
	fuLN3UA12eQI88QD20Q=; b=t3obIWZTmIHSuz/Ob/q0J52TaaMmoWrkNEMCjbGQ
	MSS6xq743SksLq+2NtZBSsKcr1SzT2dnSE3ljybeHsdJCr9RhXZYXmns+71ax4oo
	yEc1s/kCoCtBYWxt7Q1lrlG3SEZgERmv1fNd71sii6lCUc5Cuo9pFrweqoiPW0yu
	Sxg=
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.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-qe0-f54.google.com
MIME-Version: 1.0
X-Received: by 10.224.40.131 with SMTP id k3mr101420qae.23.1389761598250; Tue, 14 Jan 2014 20:53:18 -0800 (PST)
In-Reply-To: <946338.89157.bm@smtp116.sbc.mail.ne1.yahoo.com>
References: <831845 DOT 98759 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com>	<52D55D96 DOT 8070407 AT redhat DOT com>	<946338 DOT 89157 DOT bm AT smtp116 DOT sbc DOT mail DOT ne1 DOT yahoo DOT com>
Date: Tue, 14 Jan 2014 23:53:18 -0500
Message-ID: <CAG9p0OR8JYgC1rzBCn1bvXe5ffpJS3vpmnnxw-7brJi8E8+uhQ@mail.gmail.com>
Subject: Re: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
From: Lord Laraby <lord DOT laraby AT gmail DOT com>
To: Cygwin Mailing List <cygwin AT cygwin DOT com>
Content-Type: text/plain; charset=ISO-8859-1
X-IsSubscribed: yes

My two cents say, since the child is not referencing 'fp' at all,
there is no violation of the POSIX semantics in this situation. It
actually does seem, however, that the fork is closing, or at least
forgetting the stdio file position of, fp when it forks. A possible
memory corruption during fork from which fgets can not recover?

On Tue, Jan 14, 2014 at 10:50 AM,  <tednolan AT bellsouth DOT net> wrote:
> In message <52D55D96 DOT 8070407 AT redhat DOT com>you write:
>>
>>Your program may be violating POSIX, which would trigger undefined behavior.
>>
>>Quoting POSIX:
>> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
>>
>
> [long quote elided]
>
> Yikes!  That's pretty impenatrable.  And if it says what I think it says,
> it seems to violate the way I've understood Unix fork() and how fds
> (and stdio buffers) are inherited since forever.
>
> However..
>
> Do I understand that to say that if the first thing my child does is
>
>         fclose(fp);
>
> everything should be hunky-dory?
>
> Because I just tried that, and it's still not.
>
> --
> 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
>

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