coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: That '[' file in /usr/bin


From: H. Peter Anvin
Subject: Re: That '[' file in /usr/bin
Date: Sun, 03 Mar 2013 17:45:25 -0800
User-agent: K-9 Mail for Android

No, NULL is allowed because it is the list terminator.  If argc == 0 argv[0] == 
NULL.

"Pádraig Brady" <address@hidden> wrote:

>On 03/04/2013 12:01 AM, H. Peter Anvin wrote:
>> Mike Frysinger <address@hidden> wrote:
>>> On Sunday 03 March 2013 14:03:24 H. Peter Anvin wrote:
>>>> On 03/03/2013 02:53 AM, Pádraig Brady wrote:
>>>>>> personally, i find it a bit ironic that a lot of GNU apps
>>> (including
>>>>>> coreutils) simply abort() themselves when argv[0]==NULL
>>> considering the
>>>>>> project's hard line position about not relying on argv[0] for
>>> behavior.
>>>>>
>>>>> This issue was mentioned here:
>>>>>
>>>
>http://lists.gnu.org/archive/html/bug-coreutils/2009-11/msg00215.html
>>>>>
>>>>> The problem with avoiding the aborts is that NULL is only
>>>>> one of many invalid values for argv[0]
>>>>
>>>> Come again?
>>>>
>>>> You can't seriously say that checking for a null pointer or an
>>> invalid
>>>> string (for whatever definition of "valid" you happen to have) is
>>> hard.
>>>
>>> he's saying that, why special case NULL if we think this scenario is
>>> invalid.  
>>> a pointer of argv[0] = 1 will crash just as hard.
>>> -mike
>> 
>> The kernel will never pass that; that will fail at the exec side.
>
>Oh right, exec will return EFAULT.
>I guess NULL is allowed for backwards compat reasons.
>
>Looking at the actual code in gnulib, it aborts() on purpose
>when argv[0] == NULL:
>
>http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3941f59c
>
>Maybe we should output the diagnostic but continue?
>However we've not received any reports that this is an issue.
>
>thanks,
>Pádraig.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]