From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12287 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Conformance problem in system() Date: Sun, 31 Dec 2017 00:23:42 +0100 Message-ID: <20171230232342.7lc32yfg67skwzkd@voyager> References: <20171229094848.lfunfbqvjc4gln5u@voyager> <20171230222204.GF1627@brightrain.aerifal.cx> 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 1514676143 23546 195.159.176.226 (30 Dec 2017 23:22:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Dec 2017 23:22:23 +0000 (UTC) User-Agent: NeoMutt/20170609 (1.8.3) To: musl@lists.openwall.com Original-X-From: musl-return-12303-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 31 00:22:19 2017 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 1eVQSB-0005U3-Tw for gllmg-musl@m.gmane.org; Sun, 31 Dec 2017 00:22:11 +0100 Original-Received: (qmail 24313 invoked by uid 550); 30 Dec 2017 23:24:12 -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 24295 invoked from network); 30 Dec 2017 23:24:11 -0000 Content-Disposition: inline In-Reply-To: <20171230222204.GF1627@brightrain.aerifal.cx> X-Provags-ID: V03:K0:9kAqOD9QLIBRmdtrP5CPNLXRQ5j1dv15uRfhfz73tpO0OUJ+Qir gA5DZGkZqfQ2769maI/awv4b4w2zjv8kMNjPlnL6zeFCL1WWkumhD76L6YBE9FDraX7dMhy +Zw+lI4ZRvHqnBPkaKmSl7HKhbQLl6ZvWgp3FIdBT0T7tvrjS4fOXBHwgkfkIn38gjq0NoM 2zIOkZnc4k18rIJWBr3+Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:bOsaTJ3WaLo=:f8aQu35VcgfQyU9xzAf+PM N52ALlYobQ7gfuOTh6gI+qkhxHAhsVZS99y8twL2Wr0r1T14nqthQ/xgS9DrjIjzO0ItyX6JA 3YBBDjL1Z0jLqXkx40vLVkQG06OTdwsySjPLW5nowJGgEjUnqTwf2rZGzQdYz+9E+Wymu938l jxtxBqZkBhA8smXnB6iyOdsbUAsxzEf5gYAaen0ER/EKST/al73fG29w7sf/1aAYAQ1UHF7r0 aSL4/YoTCZHQuBJB4BlzkJ28zb+siNxM/V8D7K1o1YJmkk/W9jQ8CXEVprJSsbdeFedeDan4p 9G1+94w0BP3/qN6aFrXkOEREInqd7LZZk2CAhUbJhDWvlOW+tXKlksJmqKmhnd55oif+7YtKH GFYDdgGfq/HbscyTOfFb9Jaoj7KN4+ds9F/yyh2S7H5XJ2P4WfpMzEWazIDnPvoklYPWUMTuU i7DzBc1lzkM/y6/Di2YdBkmHDgvQET9xSDTwNjdLBRIrXAXuPFwqsYRycgZ+FRv8ExGpgD4qX skgMFCuf20ECDsg6QD+a5RxOcUd8nYanktIA6bcGNHLUs70343IjjzpRHuuXTvc/WHdUrOMdW GLlqwBVad6Mj+S7s/7cYRzT2yW5Ag6UU0cjOMTro8LPfkpCeZj2bzWBQMf19ogEnu3Jhbh9nU slD4eSxWYzlSwACjVEt2lFnXfGm9QSfFYHeKPTwnMHIF4zT4KAcfHJu00mCEsXMXiRS7Hcoo7 moizEie5h7iEheu90m4ysd9rF1Jzmf5/0kPJij+zm6TV+sBGIVGyFL8MVM0HH0D8eqLi+hpP Xref: news.gmane.org gmane.linux.lib.musl.general:12287 Archived-At: 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