This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Arguments to execve


On Tue, Jun 11, 2013 at 2:41 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> 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.

Initially, yes.  But with the nonnull attribute, it isn't..

But fair enough, I get your point.  POSIX doesn't require that EINVAL
be returned on a NULL pointer passed.

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

True...

> 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.

Funny you should mention it.  That's exactly how we found this....

> 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.

I apologize if this has come up before.  My search through the list
archives didn't bear any fruit related to execve.  If it has, thanks
for being patient with me.  :)

Thanks,
Pete


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]