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 06/11/2013 06:00 PM, Peter LaDow wrote:
> 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.

Exactly.

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

I'm glad to see that more people use static analysis tools these days.

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

Sorry, please don't apologize for asking a question, it's always the right
thing to do. I realize my tone might have come out harsher than it sounded.
I apologize for that. I only wished to comment on the fact that to properly
fix this issues requires real dedication. One must updated the standard,
documentation, manual pages, and example code.

In the 10+ years I've been working on the project I have not seen this
issue come up.

Without updated documentation we are all bound to repeat ourselves :-)

Cheers,
Carlos.


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