This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54


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@bellsouth.net> wrote:
> In message <52D55D96.8070407@redhat.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]