Review request for 5049299 (original) (raw)

Martin Buchholz martinrb at google.com
Tue Jun 9 18:42:04 UTC 2009

On Tue, Jun 9, 2009 at 09:28, Michael McMahon <Michael.McMahon at sun.com>wrote:

Martin Buchholz wrote:

In the old implementation, we used the strategy of fork+mutate environ+execvp and we got the traditional shell script semantics from our use of execvp. Since environ is now a global shared-with-parent variable, we can't mutate it any more, therefore can't use execvp, and must implement the missing execvpe ourselves. One more note: we could try to have two implementations of execvpe, one that mutated environ and one that didn't, since each has its own advantages, but I think that would be even harder to understand and maintain.

Hmmmmmmmmmmmmmmmmmm............................. Looking at the code again, it seems like it would not be too much work.

Here's an untested example of how we could do both.

static void execve_with_shell_fallback(const char *file, const char *argv[], const char *const envp[]) { #if USE_CLONE execve(file, (char **) argv, (char **) envp); if (errno == ENOEXEC) execve_as_traditional_shell_script(file, argv, envp); #else extern char **environ; environ = (char **) envp; execvp(file, (char **) argv); #endif }

What do you think?

Martin

Now, strictly speaking, execvp's traditional shell script semantics is an unspecified implementation detail of execvp; on other Unix platforms we might not need this. We can leave this to, e.g. the BSD porters reading this, to add some #ifdefs.

Ok, got you. (It would also be good if you ran the updated tests on Solaris with the old implementation to confirm my understanding) I'm just building it now, and will run the test then. Thanks, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090609/6406b4de/attachment.html>

More information about the core-libs-dev mailing list