Hello,
On Wed, Aug 21, 2013 at 11:06:04PM +0800, Wei-cheng Wang wrote:
> The argument arg0 should point to a filename that is associated
> with the process being started by one of the exec functions.
"should" is not "must", it is a recommendation, not a well defined one either:
"point to" is uncertain (absolute? from the caller's working directory? via
the PATH?)
There is no error code to be returned from the call which would be caused by
a situation when this (vague) constraint does not hold.
> execlp ("/bin/sh", [arg0, "foo.sh", "a", "b", "c"])
> where
> <shell path> is "/bin/sh"
> file is "foo.sh"
> arg1 is "a"
> arg2 is "b"
> arg3 is "c"
>
> So what shall the value of arg0, _the process being started_, be?
> uClibc sets arg0 to "foo.sh", while glibc, BSD libc and bionic libc
> set arg0 to "/bin/sh".
> I'm not really sure which one is right.
The first argument to exec*() is the pointer to the container
of the program to be started while the rest of the arguments are nothing
else than data bits which the caller wants to make available to the
program to be started. This does not contradict the paragraph you sited above.
I find it questionable to rewrite one of the original data arguments
and hope that this was something the caller had in mind. The library
can not be aware of how a particular application is meant to be started.
Seen from another perspective, general purpose programs interpreting
"argv[0]" are unreliable by design, as this argument is not guaranteed
to reflect anything useful. Different caller programs (e.g. shells)
set it differently, and can set it arbitrarily without contradicting
the standard.
> If, by the standrd, arg0 is not necessary <shell path>,
> I agree busybox should fix it, not uClib to workaround it.
I do not think there is any "fix" as the choice to analyze the unreliable
argv[0] is a workaround for the API deficiency. This workaround is not
feature-complete either. Busybox and similar tools are stretching POSIX
to the limits and a bit beyond :)
Regards,
Rune
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
