Mail Archives: cygwin/2014/01/15/11:34:15
--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Jan 15 10:28, tednolan AT bellsouth DOT net wrote:
> 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 b=
ehavio
> >r.
> >>>>
> >>>> Quoting POSIX:
> >>>> pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#ta=
g_15_0
> >5
> >>>>
> >>>
> >>> [long quote elided]
> >>>
> >>> Yikes! That's pretty impenatrable. And if it says what I think it s=
ays,
> >>> 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.
> >>=20
> >> 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 implementa=
tion
> >defined, so I'm not sure it will help in all situations.
> >
> >Cheers,
> >Peter
>=20
> 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? -:)
>=20
> FWIW, FreeBSD, Linux and Solaris all compile and run the test program
> with the behavoir I expect..
Just for completeness: I can test on Linux, but not on FreeBSD and
Solaris. Does the testcase also work as expected on both of them,
after you added fclose to the child? On Linux it does.
Thanks,
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJS1rhyAAoJEPU2Bp2uRE+gVXcP/jKVEtguaLpf3PQ1Qxwfxicz
CqN9tn64EZaS6TcSmIp5QtkeA6bRshvzttaYusA8KgVqAitW+JyFtwOC6PqV+JW7
mg/TxLeJoq978E+Zgypfjm5FF+7E/ZefLpXD6YvaTNLCPa1mFRDVMZf7FqbUMkjL
A2GwvIMlS1ZlGEn7nk7R7JAD1d2dTKT8hlVmoY7OMgYyu1xfoGDdKXqlsi5eSPYF
54H1g0xvT5I/UIxnt3RC3D3Qdubx0ze8sK2umsW5SO82FUqQZ5leWtJ6XWJijZxh
Gh/tOf1GqdimQdyymg8HDnQDOs3vpyma+shXMU6lHU2pOvCkA72bI9iFveasNUIR
KCxwk6xAISp9yGMo7ss56mkaXAftgtwViicnp9K9QjlVXw47dspcLwUBuR3aFxPq
FvqcWPEv0OKulOPNVu6MIKBs127lpQxfVDzre9KBO6CfRwl9sCpkFyGNxgNqVPPU
eM5cJydCNBxXVpwPjrKx5qxZL4c/goFRFV33XrVMJMyGvqdbA/DM5mGJi9ajr80T
7a6jt3CGottZQB0xcxzc4081QdV7ONVmaic2jGiV8Z+DeBWkn+/dsdYOByMGex58
J+mLHWoCRvIABmxPjtazILjg0uWOxqW1zzcOHFkSmSUivfg3aAzIdfh0upIivxNP
xAy0lt0zSAfFVDTEoanS
=1DAE
-----END PGP SIGNATURE-----
--ew6BAiZeqk4r7MaW--
- Raw text -