kern/27835: [libc] execve() doesn't conform to execve(2) spec in syscall manual

[Jilles Tjoelker]

The following reply was made to PR kern/27835; it has been noted by GNATS.

From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org, jyliu at 163.net
Cc:  
Subject: Re: kern/27835: [libc] execve() doesn't conform to execve(2) spec
	in syscall manual
Date: Fri, 17 Apr 2009 00:26:57 +0200

 POSIX says that passing 0 arguments in execve() is allowed, but an
 application doing it is not strictly POSIX compliant, and that
 applications must handle being started with 0 arguments. The Solaris 10
 man page says something similar.
 
 The test program fails with EFAULT on 7.x, but passing 0 arguments is
 still possible by changing the execve call to
   execve("/bin/sh", (char*[]){ NULL }, NULL)
 That change is good because a null pointer for argv yields undefined
 behaviour (like any function parameter outside the permitted domain).
 
 Another reason not to apply the patch to the kernel is that it uses
 EINVAL which POSIX already defines for a different purpose that seems
 useful to me: to indicate binaries with correct permissions and a valid
 file format that are not supported (e.g. wrong architecture). This
 situation currently results in ENOEXEC. Implementing the POSIX EINVAL
 could improve the 'Syntax error: "(" unexpected' message you get when
 trying to execute an ELF binary for the wrong architecture in sh; some
 other shells and the execlp(3) and execvp(3) libc functions also assume
 an executable is a shell script when they get ENOEXEC.
 
 -- 
 Jilles Tjoelker