[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171230232342.7lc32yfg67skwzkd@voyager>
Date: Sun, 31 Dec 2017 00:23:42 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Conformance problem in system()
On Sat, Dec 30, 2017 at 05:22:04PM -0500, Rich Felker wrote:
> I think you're right that there's a problem here, but I don't think
> the patch correctly or fully fixes it. A simpler version of what
> you're doing would be to just initialize status to -1 instead of
> 0x7f00, since your patch is returning -1 in all cases where waitpid
> did not complete successfully. But that ignores the POSIX requirement
> to behave as if the interpreter exited with status 127 when it was
> possibel to make the child process but the command interpreter could
> not be executed.
>
Actually, I noticed another problem: waitpid() returns the PID of the
changed child process on success, so the
if (wr) status = wr;
should be
if (wr < 0) status = wr;
The initialization of status would only change something if the kernel
did not write to status on waitpid() failure. Is that guarenteed ABI, or
does this just happen to be the case on current kernels?
> musl's posix_spawn does not succeed when exec fails in the child;
> instead the exec error is returned. This behavior is permitted but not
> required by POSIX. I think it would actually be preferable to system
> to return -1 and set errno in this case too, but POSIX doesn't seem to
> allow that.
Actually, the requirement to return exit status 127 on exec failure
sounds mighty specific to me. As if someone wanted to codify behavior
they needed in their utility. Which means there may be software out
there that depends on this behavior.
There is the possibility of not considering a posix_spawn()ed child
process as "created" unless posix_spawn() itself did return success,
though. But that might run counter to what the POSIX was going for,
here.
> So I think we actually need to break down error cases for
> posix_spawn and simulate the exit(127) result if the error returned is
> anything other than an error that could be returned by fork (EAGAIN or
> ENOMEM).
>
> Does that sound right?
Sounds correct, but I don't like it. Not least because any syscall may
fail with any errno in addition to the ones documented. But all the
solutions I can think of are even worse. In the end, it looks like POSIX
was codifying the use of fork(), exec(), and exit(127) in the child
here. Any implementation that does something different now has to work
around the mess they've made.
>
> Rich
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
