public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Paul Eggert <eggert@cs.ucla.edu>, libc-alpha@sourceware.org
Subject: Re: [PATCH 2/3] posix: execvpe cleanup
Date: Sat, 27 Feb 2016 23:18:00 -0000	[thread overview]
Message-ID: <56D1D737.6050205@linaro.org> (raw)
In-Reply-To: <56D0BA5D.5080103@linaro.org>



On 26-02-2016 17:49, Adhemerval Zanella wrote:
> 
> 
> On 26-02-2016 16:38, Paul Eggert wrote:
>> This one has similar problems with int vs ptrdiff_t. Also:
>>
>> On 02/26/2016 05:56 AM, Adhemerval Zanella wrote:
>>>   for (const char *p = path; ; p = subp)
>>>     {
>>>        if (errno == ENOEXEC)
>>>         maybe_script_execute (buffer, argv, envp);
>>
>> This has O(P*C) behavior, where P is the length of the path and C is the argument count. How about changing it to have O(P + C) behavior instead, by allocating the substitute argv in __execvpe, and reusing it each time through the loop? (Admittedly the current code also has this performance bug.)
>>
> 
> I do not oppose, although I would like to focus on fixing the usability and
> conformance bugs first and set the performance goal as possible future
> improvement. I will add a comment about this possible optimization.
> 
>>>   /* Construct an argument list for the shell.  */
>>>   char *new_argv[argc];
>>
>> This should be "argc +1", not "argc". Shouldn't we have a test case to catch bugs like this?
> 
> Indeed I will change that.  I add a testcase.
> 
>>
>>>   new_argv[0] = (char *) _PATH_BSHELL;
>>>   new_argv[1] = (char *) file;
>>>   while (argc > 1)
>>>     {
>>>       new_argv[argc] = argv[argc - 1];
>>>       --argc;
>>>     }
>>
>> This mishandles the case where argc == 1, which is possible with an empty argument vector. The resulting argument vector is not null-terminated. (Admittedly the current code also has this bug.) I suppose we should have a test case for this.
>>
> 
> I will fix that.

In fact I think original code is correct. Although execvpe is an GNU extension I
see it should follow the specification of already defined exec* POSIX functions.
And according to POSIX [1], "argv[0] should point to a filename string that 
is associated with the process being started by one of the exec functions" (this
differ with man pages with uses the wording 'by convention' to define first
argument should point to process being stated).

So I see that:

  char *args[] = { NULL }; 
  execvpe (scriptname, args, NULL)

Which triggers the issue is invalid.

  reply	other threads:[~2016-02-27 17:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26 13:57 [PATCH 0/3] posix: Execute file function fixes Adhemerval Zanella
2016-02-26 13:57 ` [PATCH 2/3] posix: execvpe cleanup Adhemerval Zanella
2016-02-26 19:40   ` Paul Eggert
2016-02-26 22:22     ` Adhemerval Zanella
2016-02-27 23:18       ` Adhemerval Zanella [this message]
2016-02-28  3:31         ` Paul Eggert
2016-02-29 17:45           ` Adhemerval Zanella
2016-02-26 13:57 ` [PATCH 3/3] posix: New Linux posix_spawn{p} implementation Adhemerval Zanella
2016-02-26 17:33   ` Joseph Myers
2016-02-26 20:07     ` Adhemerval Zanella
2016-02-26 20:49   ` Paul Eggert
2016-02-26 23:47     ` Adhemerval Zanella
2016-02-28 16:41       ` Paul Eggert
2016-02-29 18:33         ` Adhemerval Zanella
2016-02-26 14:19 ` [PATCH 1/3] posix: Remove dynamic memory allocation from execl{e,p} Adhemerval Zanella
2016-02-26 19:11   ` Paul Eggert
2016-02-26 19:44     ` Adhemerval Zanella
2016-02-26 20:13       ` Paul Eggert
2016-02-26 20:18         ` Adhemerval Zanella
  -- strict thread matches above, loose matches on Subject: below --
2016-02-29 18:33 [PATCH v5 0/3] posix: Execute file function fixes Adhemerval Zanella
2016-02-29 18:34 ` [PATCH 2/3] posix: execvpe cleanup Adhemerval Zanella
2016-02-29 19:34   ` Paul Eggert
2016-02-22 13:03 [PATCH v3 0/3] posix: Execute file function fixes Adhemerval Zanella
2016-02-22 13:03 ` [PATCH 2/3] posix: execvpe cleanup Adhemerval Zanella
2016-02-19 18:05 [PATCH v2 0/3] posix: Execute file function fixes Adhemerval Zanella
2016-02-19 18:05 ` [PATCH 2/3] posix: execvpe cleanup Adhemerval Zanella
2016-02-20  8:32   ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D1D737.6050205@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=eggert@cs.ucla.edu \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).