Re: Arguments to execve

["Carlos O'Donell" <carlos at redhat dot com>]

On 06/11/2013 04:52 PM, Peter LaDow wrote:
> On Tue, Jun 11, 2013 at 1:42 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> The standard dictates what should happen for your program to be portable
>> and standards conforming.
>>
>> The above code you quote is not portable since it violates the standard.
> 
> Exactly.  We were just surprised that it did work correctly.
> 
>> We are not going to change the behaviour of execve on Linux to return
>> EINVAL if envp is NULL since that might break non-portable programs
>> on Linux that currently work. We would break these programs for no
>> reward.
> 
> Well, I suppose the only reward would be to catch those cases where it
> is not portable.  Perhaps updating the function attribute to include
> envp as nonnull?  I.e.:
> 
> -extern int execve (__const char *__path, char *__const __argv[],
> -                   char *__const __envp[]) __THROW __nonnull ((1, 2));
> +extern int execve (__const char *__path, char *__const __argv[],
> +                   char *__const __envp[]) __THROW __nonnull ((1, 2, 3));
 
Supporting passing NULL just makes sense. There is no reason to need
a NULL terminated array if you don't need an envp.

>> It might be useful to document this shortcut of using NULL in the
>> manual pages (provided by the Kernel Man Pages project) and the glibc
>> manual (part of the glibc source e.g. manual/*).
> 
> Sure.  As long as the syscall continues to silently implement this
> shortcut.  I'll pursue an update to the man pages.

The syscall is not likely to change either.

Please also feel free to submit a patch for 
glibc's manual/process.texi (execve) section. :-)

Cheers,
Carlos.