This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Fwd: [PATCH] [BZ #18433] Check file access/existence before forking.
- From: Zack Weinberg <zackw at panix dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 18 Sep 2015 13:13:31 -0400
- Subject: Fwd: [PATCH] [BZ #18433] Check file access/existence before forking.
- Authentication-results: sourceware.org; auth=none
- References: <55F19819 dot 3010601 at gmail dot com> <55F19B66 dot 9050001 at arm dot com> <55F19C50 dot 3010502 at gmail dot com> <1441909606 dot 2948 dot 25 dot camel at pbcl dot net> <CAOUBrm2Kjbk3q+QJACYG24=p1dz60JXimxYG3oRRz2ehpocwkQ at mail dot gmail dot com> <55F299F4 dot 6030907 at arm dot com> <55FC235E dot 6030608 at redhat dot com> <55FC27CB dot 6070602 at arm dot com> <alpine dot LNX dot 2 dot 20 dot 1509181813120 dot 15988 at monopod dot intra dot ispras dot ru> <55FC2EA1 dot 7070001 at arm dot com> <CAKCAbMhpGp5qM-G-RHN9wtS+XbqJr9Cecrku77nw_sdrchci_Q at mail dot gmail dot com>
This was meant to be a reply to list.
---------- Forwarded message ----------
From: Zack Weinberg <zackw@panix.com>
Date: Fri, Sep 18, 2015 at 12:42 PM
Subject: Re: [PATCH] [BZ #18433] Check file access/existence before forking.
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
On Fri, Sep 18, 2015 at 11:32 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> that's surprising: setjmp is standard c
> and it is a macro so it cannot be called
> through a function pointer.. this is not
> true for vfork so it's not clear why gcc
> recognizes it.
Any function can be annotated with these semantics using __attribute__
((returns_twice)), but glibc's headers don't do that, so GCC must have
special knowledge of the name 'vfork'; and this probably _is_ a
conformance violation, in that a program that doesn't include
<unistd.h> (or includes it in a feature-selection mode that doesn't
bring in a declaration of 'vfork') ought to be allowed to define its
own 'vfork' that has no such semantics. (As far as I know, vfork is
_not_ in POSIX nor XSI.) I don't see any way around it, though.
Breaking programs that call vfork, expecting it to have its special
behavior, would be worse. And I expect the code-generation changes
are not _wrong_ in the case that vfork doesn't return twice, just less
optimal.
And yes, I expect Bad Things happen if someone calls vfork through a
function pointer.
zw