When I use the function getenv() from the Standard C Library, my program inherit the environment variables from its parent.
Example:
$ export FOO=42
$ <<< 'int main() {printf("%s\n", getenv("FOO"));}' gcc -w -xc - && ./a.exe
42
In libc, the environ variable is declared into environ.c. I am expecting it to be empty at the execution, but I get 42.
Going a bit further getenv can be simplified as follow:
char * getenv (const char *name)
{
size_t len = strlen (name);
char **ep;
uint16_t name_start;
name_start = *(const uint16_t *) name;
len -= 2;
name += 2;
for (ep = __environ; *ep != NULL; ++ep)
{
uint16_t ep_start = *(uint16_t *) *ep;
if (name_start == ep_start && !strncmp (*ep + 2, name, len)
&& (*ep)[len + 2] == '=')
return &(*ep)[len + 3];
}
return NULL;
}
libc_hidden_def (getenv)
Here I will just get the content of the __environ variable. However I never initialized it.
So I get confused because environ is supposed to be NULL unless my main function is not the real entry point of my program. Perhaps gcc is ticking me by adding an _init function that is part of the standard C library.
Where is environ initialized?
The environment variables are passed down from the parent process as a third argument to main. The easiest way to discover this is to read the documentation for the system call execve, particularly this bit:
int execve(const char *filename, char *const argv[], char *const envp[]);Description
execve()executes the program pointed to byfilename. [...]argvis an array of argument strings passed to the new program. By convention, the first of these strings should contain the filename associated with the file being executed.envpis an array of strings, conventionally of the formkey=value, which are passed as environment to the new program. Bothargvandenvpmust be terminated by a NULL pointer. The argument vector and environment can be accessed by the called program's main function, when it is defined as:int main(int argc, char *argv[], char *envp[])
The C library copies the envp argument into the environ global variable somewhere in its startup code, before it calls main: for instance, GNU libc does this in _init and musl libc does it in __init_libc. (You may find musl libc's code easier to trace through than GNU libc's.) Conversely, if you start a program using one of the exec wrapper functions that don't take an explicit environment vector, the C library supplies environ as the third argument to execve. Inheritance of environment variables is thus strictly a user-space convention. As far as the kernel is concerned, each program receives two argument vectors, and it doesn't care what's in them.
(Note that three-argument main is an extension to the C language. The C standard only specifies int main(void) and int main(int argc, char **argv) but it permits implementations to define additional forms (C11 Annex J.5.1 Environment Arguments). The three-argument main has been how environment variables work since Unix V7 if not longer, and is documented by Microsoft too — see What should main() return in C and C++?.)
There is no mystery here.
First, the shell forks. Forked process obviously has the same environment. Then a new program is executed in the child. The syscall in question is execve, which amongst other things accepts a pointer to an environment.
So there, what environment is set after execing a binary depends entirely on the code which was doing the exec.
All this is can be easily seen by running strace.
EDIT: since the question was edited to ask about environ:
When you execute a dynamically linked binary, the very first userspace code doing anything comes from the loader. The loader amongst other things sets up variables like argc, argv or environ and only then calls main() from the binary.
Once more, sources for all this are freely available. While glibc's sources are rather hard to read due to atrocious formatting, BSD ones are easy and conceptually equivalent enough.
http://code.metager.de/source/xref/freebsd/libexec/rtld-elf/rtld.c#389
Under Linux when a program starts it has its arguments and environmental variables stored on the stack. For C programs the code that executes before main looks at this, makes the argv and envp arrays of pointers, and then calls main with these values (and argc).
When a program calls execvpe to turn into a new program (often after calling fork) then an envp is passed in, along with an argv. The kernel will copy the data at these into the new program's stack.
When any of the other exec functions are called then the glibc will pass in the current program's environ as the new program's envp to execvpe (or directly to sys_exec).