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:from:to:subject:in-reply-to
	:references:date; q=dns; s=default; b=HMOjC+20mnwNT33ifVbjEsCt2U
	5Sbaidsc67ymsOW98rLdKI5ICrOOUwO0sUT7T7l3v3bqUq17I9MF+D4ABLF8sOcz
	a8gZvk/46SazDHxzWELcFUvoYhJLVUCXZWgUDPNh+sAT7kkI4Zvs9MuhMdnNNg7e
	smMF93ovL42f41IQk=
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:from:to:subject:in-reply-to
	:references:date; s=default; bh=Kprri39K11y1yCtLuSanaQLiAo0=; b=
	YteRKVUobVF2Hop5sAtjtAnUij3KUYRwIbZFIO7ETCeyiA2uBU0AfvRavVdYx6ey
	U7YqzXnyTOzkx+aC+gy5a1x5jxDFx6Qh+qnZeoNgjDv5dvmU+jJMK6ZOrOQQJAb1
	+Yf3yutd1KDGfa2nFsTgPhpZt1OIP7qWLmoZqPFH+Mk=
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=0.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO:	nm16-vm8.access.bullet.mail.gq1.yahoo.com
Message-ID:	<858084.71265.bm@smtp116.sbc.mail.ne1.yahoo.com>
X-Yahoo-SMTP:	BDVluRmswBBpb4.UU1_zlPhs_ysfXcBVjBNXyWpyS_6pPgE-
X-Rocket-Received:	from solabel10.tnolan.com (tednolan AT 74 DOT 243 DOT 198 DOT 131 with plain [98.138.84.52]) by smtp116.sbc.mail.ne1.yahoo.com with SMTP; 15 Jan 2014 15:52:58 +0000 UTC
From:	tednolan AT bellsouth DOT net
To:	cygwin AT cygwin DOT com
Subject:	Re: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
In-reply-to:	<52D63CE2.9060308@lysator.liu.se>
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> <CAG9p0OR8JYgC1rzBCn1bvXe5ffpJS3vpmnnxw-7brJi8E8+uhQ AT mail DOT gmail DOT com> <52D63CE2 DOT 9060308 AT lysator DOT liu DOT se>
Comments:	In-reply-to Peter Rosin <peda AT lysator DOT liu DOT se> message dated "Wed, 15 Jan 2014 08:46:42 +0100."
Date:	Wed, 15 Jan 2014 10:28:05 -0500
X-IsSubscribed:	yes

In message <52D63CE2 DOT 9060308 AT lysator DOT liu DOT se>you write:
>On 2014-01-15 05:53, Lord Laraby wrote:
>> On Tue, Jan 14, 2014 at 10:50 AM, Ted Nolan wrote:
>>> In message <52D55D96 DOT 8070407 AT redhat DOT com> you write:
>>>>
>>>> Your program may be violating POSIX, which would trigger undefined behavio
>r.
>>>>
>>>> Quoting POSIX:
>>>> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_0
>5
>>>>
>>>
>>> [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.
>> 
>> 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?
>
>Let me requote one little bit quoted by Eric:
>
>	                           (If the only action performed by one of the
>	processes is one of the exec functions or _exit() (not exit()), the
>	handle is never accessed in that process.)
>
>Ted is using exit() in the children, not _exit(), and the above indicates
>that exit() in fact "accesses the handle". My guess would be that fclose(3)
>also "accesses the handle".
>
>But, reading about _exit(), it seems that handle accesses are implementation
>defined, so I'm not sure it will help in all situations.
>
>Cheers,
>Peter

Well, all I can say in this instance, is that arguably conforming to
the bare letter of the standard (if that's in fact what is happening)
is not "the right thing".  People certainly don't expect that stdio
file pointers that exist at fork() time and which are never "used" by a
child will be reset in the parent.  I mean, if they can't even be fclose()-ed
to take them out of the picture, what chance have you got? -:)

FWIW, FreeBSD, Linux and Solaris all compile and run the test program
with the behavoir I expect..


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