[Lazarus] SetEnv on Linux 64bit

[michael.vancanneyt at wisa.be]

On Wed, 4 Apr 2012, Honza wrote:

> 2012/4/4  <michael.vancanneyt at wisa.be>:
>> 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.
>
> Why not permissible? The POSIX specs describe what the semantics
> and/or effects of executing a defined function are. The semantics and
> effects of libc's execv() are what is said about it in POSIX. I don't
> see any 'off' conclusion derivable ;-)

>
>> 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.
>
>> From the moment main() starts executing, environ is the process
> current environment. Initially, as it was passed, after any mutation
> well, that mutated state. No copy of the original environment of a
> process exists anywhere in the process nor in the kernel.

I think you'll find that the environment block is copied as soon as you
add a new environment variable.

Since the original environment as passed by the kernel is not in the heap, 
so how could you add something to it, except by copying the array
of pointers and enlarging it ?

What happens to it in a library, is currently open for speculation.

>  A copy might
> still exists, though not necessarily, in the originating process, but
> that is anyway not accessible by the new/now executing process (modulo
> shmem etc.).
>
> Also the 'external variable' is just a reference to the C
> specification, i.e. that's the way C says to the linker to find the
> variable defined elsewhere, not in this compilation unit/produced
> object code.

I agree a C person might interpret it like that.

>
>> Which probably is what happens if you'd call the
>> execv() kernel function, although that would need testing.
>
> I can perhaps save someone's time, as there's no execv() kernel call.
> There's only execve() and that's why a POSIX compliant libc calls
> execve() with the current value of environ.

I stand corrected on this front.

>
>> Thirdly, the 2 referenced pages clearly indicate that the whole environment
>> handling is hairy at best in corner cases like this.
>
> Perhaps, not relevant to us, IMO.
>
>> 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.
>
> No one said so. Actually that's just fine. The discussion went about
> various claims from various people that in POSIX the environment is
> either immutable at all, or the mutations are not visible in
> libraries, or not inherited on exec() - we (you and me) were not
> discussing FPC at all, IMO.

Yes. I was sloppy in my terminology.

>
> AFAICS, all the above claims were not true. Actually it's the first
> time ever I saw such claims, as mutating environment in a POSIX
> program, because of child process inherits that by default, is so
> common, that I have never even thought before of a possibility it
> could be otherwise, so I wanted to verify, to my own benefit, "how
> that stuff I never really looked into actually works" ;-)

I think the confusion came from the original posters request to 
modify the 'global environment', which - I hope you'll agree -
is not possible on Posix, as the environment is passed on from 
process to process using execve.

So, my conclusions:

* The SetEnvironment() call on windows will do something totally
   different than what happens under Posix, and the Windows behaviour
   cannot be mimicked. Which is why it isn't in sysutils.

* A posixy SetEnv() could be implemented for the Unix layer, to mimic
   Libc. But I think it would not be usable for libraries, since the
   environment copy of the RTL would not be shareable with the library
   without pulling in the C memory manager.
   At best it could be used to be passed on to a new process.

Michael.