[Lazarus] SetEnv on Linux 64bit

Honza befelemepeseveze at gmail.com
Wed Apr 4 15:37:15 CEST 2012


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. 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.

> 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.

> 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.

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" ;-)

-- jnml

PS: I think there's no reason why a SetEnv should not by available in
sysutils (or system, or ...) on POSIX systems, and as other languages
demonstrate, such call can work seamlessly on Windows too. And as FPC
is a cross platform compiler.... Actually I think if there is GetEnv
somewhere and its natural counterpart SetEnv is nowhere, then it's
quite surprising - don't know about a similar example with some other
language.




More information about the Lazarus mailing list