Re: [PATCH] [BZ #18433] Check file access/existence before forking.

[Phil Blundell <pb at pbcl dot net>]

On Fri, 2015-09-11 at 02:15 +0430, navid Rahimi wrote: 
> I agree with you completely about overhead and extra syscall , but
> there is no other option if we want to check fork. About optimizing
> failure case , I would not call it optimizing , I returning correct
> error code and correct answer to caller at expense of one extra
> syscall overhead . 

Well, right, but I still don't understand why this is desirable.

A portable application can't rely on this behaviour since, as I wrote in
the bugzilla ticket earlier, POSIX explicitly allows an implementation
to not detect errors before fork()ing and instead to have the child do
exit(127); and as far as I can tell glibc is already doing this
correctly.  So there doesn't seem to be any conformance problem here; at
most we're talking about a QoI issue.

An application which is particularly worried that it might be about to
posix_spawn() a nonexistent executable can always do the access() check
for itself beforehand.  Alternatively it could look for the exit code
127 and then try to figure out retrospectively why the spawn() would
have failed by poking around with access().  But it remains a bit
unclear to me why the application would really need to know since, even
if it can determine why posix_spawn() failed, it's not obvious that it
can take any meaningful steps to fix the problem.

Do you have a concrete use-case where having a specific failure return
from posix_spawn() is important?

p.