This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Arguments to execve
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Peter LaDow <petela at gocougs dot wsu dot edu>
- Cc: libc-help at sourceware dot org
- Date: Tue, 11 Jun 2013 17:41:41 -0400
- Subject: Re: Arguments to execve
- References: <CAN8Q1Ed1KDrmjbSxd74XVQFWEUvbbpaq0dQFJ9OLPapgxf2pyw at mail dot gmail dot com> <51B78BCC dot 1020400 at redhat dot com> <CAN8Q1Ec31RbOSJZ-6wDkyE6+eD+HAsRPxzVUGYHuwXnx==QFXA at mail dot gmail dot com> <51B7925B dot 9060605 at redhat dot com> <CAN8Q1EfScfa2e03qZeUcFo5gzBrmfhmpErJn2FHnfM2H3rtWOw at mail dot gmail dot com>
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.