Misha TyurinКороче, я уже тут много че делал и с этим кодом и подобными, тут есть вот какя фигня:

!!!! если поставить "\n" выше развилки - ТО ВСЁ РОВНО, как и интуитовно понятно,

а если как я привел в самом начале, то имеем то что получается, ВЫВОД ДВАЖДЫ того что не должно так выводится

Очень даже правильное поведение.
Несброшенный буфер printf наследуется процессом потомком.

Misha TyurinДа, как я понимаю этот буфер (точнее его свои копии) оба процесса использовали и когда потом он влешится то и выводится, но оба имеет в буфере первый принтф.

Просто хочется услышать как там всё это на самом деле реально чё куда передается при "развилке". Сталкнулся с этим и ещё сильнее понял что нифига наверняка не знаю.

В Linux на самом деле так:

LINUX man fork
fork creates a child process that differs from the parent process only
in its PID and PPID , and in the fact that resource utilizations are
set to 0. File locks and pending signals are not inherited.

Under Linux, fork is implemented using copy-on-write pages, so the
only penalty incurred by fork is the time and memory required to
duplicate the parent's page tables, and to create a unique task struc-
ture for the child.


В AIX так:

AIX man fork

The fork subroutine creates a new process. The new process (child
process) is an almost exact copy of the calling process (parent
process). The child process inherits the following attributes from the
parent process:
* Environment
* Close-on-exec flags (described in the exec (exec: execl, execle,
execlp, execv, execve, execvp, or exect Subroutine) subroutine)
* Signal handling settings (such as the SIG_DFL value, the SIG_IGN
value, and the Function Address parameter)
* Set user ID mode bit
* Set group ID mode bit
* Profiling on and off status
* Nice value
* All attached shared libraries
* Process group ID
* tty group ID (described in the exit (exit, atexit, unatexit,
_exit, or _Exit Subroutine), atexit, or _exit subroutine, signal
subroutine, and raise subroutine)
* Current directory
* Root directory
* File-mode creation mask (described in the umask subroutine)
* File size limit (described in the ulimit subroutine)
* Attached shared memory segments (described in the shmat
subroutine)
* Attached mapped file segments (described in the shmat subroutine)
* Debugger process ID and multiprocess flag if the parent process
has multiprocess debugging enabled (described in the ptrace
(ptrace, ptracex, ptrace64 Subroutine) subroutine).

The child process differs from the parent process in the following
ways:
* The child process has only one user thread; it is the one that
called the fork subroutine.
* The child process has a unique process ID.

* The child process ID does not match any active process group ID.
* The child process has a different parent process ID.
* Process locks, text locks, and data locks are not inherited by the
child process. For information about locks, see the plock (plock
Subroutine) subroutine.
* If multiprocess debugging is turned on, the trace flags are
inherited from the parent; otherwise, the trace flags are reset.
For information about request 0, see the ptrace (ptrace, ptracex,
ptrace64 Subroutine) subroutine.
* The child process utime, stime, cutime, and cstime subroutines are
set to 0. (For more information, see the getrusage (getrusage,
getrusage64, times, or vtimes Subroutine), times, and vtimes
subroutines.)
* Any pending alarms are cleared in the child process. (For more
information, see the incinterval (getinterval, incinterval,
absinterval, resinc, resabs, alarm, ualarm, getitimer or setitimer
Subroutine), setitimer (getinterval, incinterval, absinterval,
resinc, resabs, alarm, ualarm, getitimer or setitimer Subroutine),
and alarm (getinterval, incinterval, absinterval, resinc, resabs,
alarm, ualarm, getitimer or setitimer Subroutine) subroutines.)
* The set of signals pending for the child process is initialized to
the empty set.
* The child process can have its own copy of the message catalogue
for the parent process.
* The set of signals pending for the child process is initialized as
an empty set. Attention: If you are using the fork or vfork
subroutines with an Enhanced X-Windows, X Toolkit, or Motif
application, open a separate display connection (socket) for the
forked process. If the child process uses the same display
connection as the parent, the X Server will not be able to
interpret the resulting data.

* The child process has its own copy of the file descriptors for the
parent process. However, each file descriptor of the child process
shares a common file pointer with the corresponding file
descriptor of the parent process.
* All semadj values are cleared. For information about semadj
values, see the semop subroutine.



Других Юниксов под рукой нет, предлагаю погугилить самостоятельно.
А поведение у них приблизительно одинаковое.