Arguments to execve

[Carlos O'Donell]

On 06/11/2013 05:30 PM, Peter LaDow wrote:
> On Tue, Jun 11, 2013 at 2:10 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> Supporting passing NULL just makes sense. There is no reason to need
>> a NULL terminated array if you don't need an envp.
> 
> I agree.  And I think that was the though process when this code was
> originally written.

Agreed.
 
> But for the sake of discussion, passing NULL for envp violates POSIX
> (no?).  And if POSIX compliance is a goal....

We *are* POSIX compliant, it's the application that is at fault,
and undefined behaviour can be anything, including working correctly.

You are asking for glibc to *prevent* the application from being 
non-compliant, at the cost of an extra check in the hot path of
execve.

In general glibc does not try to enforce compliance where the standard
doesn't require us to do so. There is FORTIFY_SOURCE, but that is used
to catch security issues, and I've seen no argument for that.

> And adding the envp parameter to the nonnull attribute only generates
> a warning.  Calls using a NULL envp would still function correctly,
> but the author would at least be notified of the non-compliance.  Just
> a thought.

You would break any build using gcc and -Werror, and that's equally
complicated because it would require changing source.

We walk a fine line here, and a static analysis tool would do a much
better job of catching this than forcing such a warning for a NULL
envp which we all agree should really be allowed.

Which leads one down the lengthy path of comparing UNIX
implementations, and seeing if the POSIX text can actually be adjusted
to allow envp being NULL as an alias for { NULL }.

That would really be the right thing to attempt, that way the standard
is updated based on common practice and we don't need to have this
conversation again between two different people every 5 years.

>> The syscall is not likely to change either.
> 
> Indeed.  The code in 3.0 vs 3.10 looks nearly identical.  I don't
> anticipate a change either.

Agreed.

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

Thanks Pete!

Cheers,
Carlos.