Hi,
a bug report of a GPC user drew my attention to a possible problem with the `environ' libc variable (which is currently declared for Pascal as `Environment' in gpc.pas).
After some research I found that Linux/libc5 (which I'm using) seems to be the only system which has environ declared in <unistd.h>. Linux/glibc declares it, but only if `_GNU_SOURCE' is defined.
All the other systems I tried (DJGPP, Solaris, Irix) don't declare the variable, but still have it, i.e. when I declare it as `extern' manually, it is there. (Yeah, that's C...)
Now, `environ', as the name suggests, contains the current environment variables, i.e. the ones that were set when the process started plus the ones the process set itself (by setenv() or putenv()).
Another way to get at the environment is the third parameter to `main' (which GPC could access internally, that's not a problem). However, this variable only contains the environment at the start of the process. When the process does some putenv()s, the pointer gets invalid (DJGPP), or the environment pointed to just seems to be unmodified (the other systems I tested). Perhaps the DJGPP behaviour is a bug, I don't know, but in any case the parameter is not useful to get the current environment at a later time.
So, does anybody know what's the matter with `environ'? Can one just declare it as `extern char **environ;' even if it's not declared in any header? Or is there another way to get at the current environment?
If not, in the worst case, this would mean that the GPC RTS has do to its own environment handling, i.e. get the initial environment for the `main' parameter, and provide its own versions of getenv() and putenv() which work on a copy of that. Though it would not be terribly much work, I hope to avoid it...
The following C (sorry;-) program demonstrates the effect. It will first print `environ', then the environment pointed to by the third parameter, at the start of the program (these should be identical), then do 1000 putenv()s (it can take quite a few of them to make the problem apparent ;-), then print `environ' again (which does contain the new variables on all systems I tried), and the parameter again (which does not show any changes, and under DJGPP even crashes the program).
Frank