On Mon, 30 Oct 2006 10:53:27 -0500 Greg Nakhimovsky - Sun MDE wrote: > Glenn Fowler wrote: > ... > > I fixed those, but posix_spawn() was still found unworthy > > the reason is that at least on solaris 10, posix_spawn() returns 0 (success) > > when the executable file is empty > > truss shows the underlying execve() getting ENOEXEC (which it should), > > but that errno fails to make its way back as the posix_spawn() return value > > > > note that linux posix_spawn() is not worthy for the same reason
> Most likely, posix_spawn() is supposed to return 0 (success) when > the executable file is empty. It IS a little weird and confusing > indeed, but that's how POSIX defined this interface. first let's clarify that "empty" is not the key characteristic here any content besides a valid a.out magic number still results in "success" even though the underlying implementation fails with ENOEXEC the posix_spawn() spec is careful to use the same language (regular executable file) as it does for execv() -- execv() returns failure with errno set to ENOEXEC for executable files with bad magic it specifically states that the executable file shall be executed as if "a member of the exec family of functions had been called by the child process to execute the new process image" any reading of posix_spawn() that allows it to return 0 (success) for regular executable files on which execv() would fail is flawed otherwise how could a shell using posix_spawn() know that an execution actually failed? after all, the prototypical method of marching down PATH is to exec() with each PATH element until success or the PATH is exhausted -- Glenn Fowler -- AT&T Research, Florham Park NJ --
