Date: Thu, 16 Apr 2009 22:30:02 GMT From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-standards@FreeBSD.org Subject: Re: kern/27835: [libc] execve() doesn't conform to execve(2) spec in syscall manual Message-ID: <200904162230.n3GMU2lL042689@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/27835; it has been noted by GNATS. From: Jilles Tjoelker <jilles@stack.nl> To: bug-followup@FreeBSD.org, jyliu@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904162230.n3GMU2lL042689>