Yes, you are correct.
In particular, this means that the child will inherit all variables from the parent process with the value they had at the moment of the fork. However, if at a later step one of the parent or the child modifies one of these variables, the modification will be local to this process: if the child modify a variable, the parent process will still see the old value and not the new one.
With forks, if you want the child and parent process to communicate you will need to use some explicit inter-process communication.
This is the difference with threads. Conceptually forks and threads look the same: the same code being executed by two processes in the case of forks and two threads in the case of threads. However, in the case of threads the address space will not be copied: the two threads will share the same memory, so if one thread modify a variable, it will impact all other threads.
Threads therefore allows a very flexible communication between the threads, but this is also very error prone because of the high probability of race conditions if not used carefully.
Both systems are address different needs. As a side note, the fork primitive is usually implemented in a clever way on the system side since the address space will not be physically copied, but the system will use a copy-on-write system: data will be duplicated only if one of the processes attempts to actually modify it. While the data is not modified it will not be duplicated and will therefore not consume more memory.
More information regarding forks and thread can be found on StackOverflow.
:
Best Answer
After fork, you have two copies of the same program. The kernel can either copy all of the address space or copy-on-write. In the latter case, the text and data sections will probably always be shared by both processes, and the stack will be copied IF the child needs to modify it, so on and so on.