On Wed, 4 Apr 2012, Honza wrote:
2012/4/4 <[email protected]>:
Output of strace:
brk(0) = 0x21a5000 brk(0x21c6000)
= 0x21c6000 write(1, "a2: MYVALUE\n", 12a2: MYVALUE )
= 12 execve("./b.out", [0], [/* 57 vars */]) = 0 brk(0)
= 0x189e000 access("/etc/ld.so.nohwcap", F_OK) = -1
ENOENT (No such file or
directory)
As you can see, it uses execve() behind the scenes to be able to pass the
modified
local environment.
This is libc-specific behaviour.
I think I cannot agree. IMO its a POSIX specified behavior. libc, at
least in this case, just implements the POSIX specs:
http://pubs.opengroup.org/onlinepubs/007904975/functions/exec.html
And as the ouptut of executing a.out shows, libc implements it
correctly: "For those forms not containing an envp pointer ( execl(),
execv(), execlp(), and execvp()), the environment for the new process
image shall be taken from the external variable environ in the calling
process.", which libc achieves by calling execve() with the current
environ, effectively just filling the prescribed default.
I do not agree with this interpretation.
First of all, you are calling execv() in your code, not execve().
That libc changes this to execve() is IMHO not permissible.
So all bets and conclusions are off from that point onwards.
Secondly, we interpret differently 'external variable environ'. (note the
'external'). For me this clearly means the original environment as passed
on to the current process. Which probably is what happens if you'd call the
execv() kernel function, although that would need testing.
Thirdly, the 2 referenced pages clearly indicate that the whole environment
handling is hairy at best in corner cases like this.
And lastly: We on purpose do not follow Libc;
Otherwise we'd simply have built the whole RTL on top of it.
So we are not under any obligation to mimic its behaviour.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
