From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12346 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Conformance problem in system() Date: Tue, 9 Jan 2018 13:03:47 -0500 Message-ID: <20180109180347.GB1627@brightrain.aerifal.cx> References: <20171229094848.lfunfbqvjc4gln5u@voyager> <20171230222204.GF1627@brightrain.aerifal.cx> <20171230232342.7lc32yfg67skwzkd@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1515520936 15082 195.159.176.226 (9 Jan 2018 18:02:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Jan 2018 18:02:16 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12362-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 09 19:02:12 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eYyDq-0002zX-64 for gllmg-musl@m.gmane.org; Tue, 09 Jan 2018 19:02:02 +0100 Original-Received: (qmail 5238 invoked by uid 550); 9 Jan 2018 18:04:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5196 invoked from network); 9 Jan 2018 18:03:59 -0000 Content-Disposition: inline In-Reply-To: <20171230232342.7lc32yfg67skwzkd@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12346 Archived-At: On Sun, Dec 31, 2017 at 12:23:42AM +0100, Markus Wichmann wrote: > 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. I think this is an acceptable interpretation for now. So just changing default initialization of status to -1 should work, right? Rich