|
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.