From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40049 invoked by alias); 12 Sep 2015 19:03:50 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 39996 invoked by uid 48); 12 Sep 2015 19:03:46 -0000 From: "nachms+sourceware at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/18433] posix_spawn does not return correctly upon failure to execute Date: Sat, 12 Sep 2015 19:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.19 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nachms+sourceware at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-09/txt/msg00148.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=18433 --- Comment #3 from Nach M. S. --- Note the return value (emphasis included): Upon successful completion, posix_spawn() and posix_spawnp() shall return the process ID of the child process to the parent process, in the variable pointed to by a non-NULL pid argument, and shall return zero as the function return value. Otherwise, no child process shall be created, the value stored into the variable pointed to by a non-NULL pid is unspecified, ***and an error number shall be returned as the function return value to indicate the error***. If the pid argument is a null pointer, the process ID of the child is not returned to the caller. You are correct that the standard allows to exit with 127, however it discourages that behavior and says only if the library is unable to detect all issues is it okay to do so. I can't speak for other platforms, but it is perfectly possible to implement this function in a library on Linux in a feature-complete fashion. FreeBSD, NetBSD, and musl-libc (Linux) at the library level are all capable of detecting the errors and properly returning them without any special kernel supports. I've also implemented this function on Linux correctly and feature-complete with proper error handling, and it's not really a big deal to do so. Using any simple form of IPC, the error can be returned from the child to the parent. The BSDs use vfork() with a variable that the child modifies and the parent looks at. musl-libc uses a pipe. Personally, I recommend the latter approach. -- You are receiving this mail because: You are on the CC list for the bug.