fork problem

[mishra]

Hi,
i thied the following code..
# include<stdio.h>
int main()
{
int a;
printf("Hello...");
a=fork();
printf("hi\n");
return(0);
}

the o/p is as follows..
rapti:~/prg [\>] > ./a.out
Hello... hi
Hello... hi

but when i gave
# include<stdio.h>
int main()
{
int a;
printf("Hello...\n"); // mark the \n here
a=fork();
printf("hi\n");
return(0);
}

the o/p became ..
rapti:~/prg [\>] > ./a.out
Hello...
hi
hi

can any one tell me how that \n is affecting?
and insted of the printf statement if i put some thing else.. that is
not getting evaluated two times...

please help me out...
regard
Mishra

[Johan Borkhuis]

mishra wrote:

Hi,
i thied the following code..
# include<stdio.h>
int main()
{
int a;
printf("Hello...");
a=fork();
printf("hi\n");
return(0);
}

the o/p is as follows..
rapti:~/prg [\>] > ./a.out
Hello... hi
Hello... hi

but when i gave
# include<stdio.h>
int main()
{
int a;
printf("Hello...\n"); // mark the \n here
a=fork();
printf("hi\n");
return(0);
}

the o/p became ..
rapti:~/prg [\>] > ./a.out
Hello...
hi
hi

can any one tell me how that \n is affecting?
and insted of the printf statement if i put some thing else.. that is
not getting evaluated two times...
Looks like printf is buffering data until it gets a newline. As you fork
the original process the data for printf is also copied to the new
context, and so you see the data appear twice.
If you would change this you could try using unbuffered output.

Kind regards,
Johan

--
o o o o o o o . . . _____J_o_h_a_n___B_o_r_k_h_u_i_s___
o _____ || http://www.borkhuis.com |
.][__n_n_|DD[ ====_____ | jo***@borksoft.xs4all.nl |(________|__|_[_________]_|________________________________|

_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
== VxWorks-page: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ==

[ng5000]

Ok,

If remember correctly (I', sure you'll let me know if not!):

'\n' causes the stdout buffer to be flushed, i.e. as soon as '\n' is
parsed the contents will, in this case, be displayed on screen. In the
first example you don't flush the buffer so 'Hello' will still be in
the buffer waiting to be outputted. fork () returns twice, once as the
parent process and once as the child process. The child process's
memory will be a copy of the parent process's memory (i.e. both
processes will have the same data in memory), so a copy of stdout's
buffer (which contains "Hello") will exist for both processes. When
you then go on to send "hi\n" to stdout the buffer is flushed causing
"Hello" to be displayed by both the parent and the child.

In order to better understand how fork () works you should be checking
it's return value (remembering that it returns twice) so that you can
print whether you are in the parent or the child.

Nick

[Antonio]

mishra wrote:

Hi,
i thied the following code..
# include<stdio.h>
int main()
{
int a;
printf("Hello...");
a=fork();
printf("hi\n");
return(0);
}

the o/p is as follows..
rapti:~/prg [\>] > ./a.out
Hello... hi
Hello... hi

but when i gave
# include<stdio.h>
int main()
{
int a;
printf("Hello...\n"); // mark the \n here
a=fork();
printf("hi\n");
return(0);
}

the o/p became ..
rapti:~/prg [\>] > ./a.out
Hello...
hi
hi

can any one tell me how that \n is affecting?
and insted of the printf statement if i put some thing else.. that is
not getting evaluated two times...

please help me out...
regard
Mishra

This is my first post here, but I think I can help there. This strange
behaviour is caused because of the way that stdout behaves. Stdout is
line buffered, wich means that when you write to it, in truth you're
writting to a buffer that doesn't get "flushed" until a new line
character is written to the buffer.

In your first example, you write to stdout, but don't place any new
line character, so the actual write to console is delayed. Then you
make a fork, wich creates a copy of the process, including the buffer
to stdout. When you make the second printf, the buffer is flushed, so
both processes write the same to stdout.

In the second example, since there is a new line character in the first
printf, the buffer has been flushed, and so both processes after the
fork have an empty buffer to stdout.

So to summarize, the first printf is only executed once, as would be
any sentence that you could place before the fork. But it's effects are
replicated by the line buffering of stdout.

Hope that helped.

[SM Ryan]

# This is my first post here, but I think I can help there. This strange
# behaviour is caused because of the way that stdout behaves. Stdout is
# line buffered, wich means that when you write to it, in truth you're

In this case, it is almost certainly line bufferred, but that does not
have to be generally true of stdout. To force the bufferring behaviour,
use the setvbuf function.

As a general rule, force stdio buffer flushes of all writable FILEs
before forking. You can also use fflush for this.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
No pleasure, no rapture, no exquisite sin greater than central air.

[Keith Thompson]

"mishra" <mi******@gmail.com> writes:

i thied the following code..
# include<stdio.h>
int main()
{
int a;
printf("Hello...");
a=fork();
printf("hi\n");
return(0);
}

the o/p is as follows..
rapti:~/prg [\>] > ./a.out
Hello... hi
Hello... hi

[snip]

There is no fork() function in standard C. Try comp.unix.programmer
(where they'll tell you, among other things, that you should #include
the proper system-specific header before using fork().)

If you invoked your compiler properly, it should warn you that fork()
is undeclared. If you're using gcc, try "gcc -ansi -pedantic -W -Wall";
change "-ansi" to "-std=c99" if you want to take advantage gcc's
incomplete C99 support. If you're using a compiler other than gcc,
check its documentation.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jack Klein]

On 19 Jul 2005 05:23:58 -0700, "Antonio" <an*****@gmail.com> wrote in
comp.lang.c:

mishra wrote:

Hi,
i thied the following code..
# include<stdio.h>
int main()
{
int a;
printf("Hello...");
a=fork();
printf("hi\n");
return(0);
}

the o/p is as follows..
rapti:~/prg [\>] > ./a.out
Hello... hi
Hello... hi

but when i gave
# include<stdio.h>
int main()
{
int a;
printf("Hello...\n"); // mark the \n here
a=fork();
printf("hi\n");
return(0);
}

the o/p became ..
rapti:~/prg [\>] > ./a.out
Hello...
hi
hi

can any one tell me how that \n is affecting?
and insted of the printf statement if i put some thing else.. that is
not getting evaluated two times...

please help me out...
regard
Mishra

This is my first post here, but I think I can help there.

Since it's your first post here, I'll point this out:

The question is off-topic and any attempts to answer it in detail are
off-topic. The topic of this newsgroup is the C language, which is
specifically and completely defined originally by the two editions of
K&R, then, since 1989, by various ANSI/ISO International Standards.

fork() is not part of the C language or its libraries. It is a
non-standard (from the point of the language and this newsgroup)
extension provided by some particular compiler and operating system
combinations.

The UNIX API does not define the C language. The Windows API does not
define the C language.

In cases like this, the only appropriate reply is to redirect the
poster to a group where his question is topical, if one knows of one.
In this case news:comp.unix.programmer would be a good choice.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[SM Ryan]

Jack Klein <ja*******@spamcop.net> wrote:

# The question is off-topic and any attempts to answer it in detail are

It is most definitely on-topic unless you think setbuffer, setvbuf,
printf, stdout, and _everything_ else in <stdio.h> is off-topic.
The question is about how does stdio bufferring work, not how does
fork work. A similar issue would show up if the program aborts and
appears to lose part of the output: until you know some output can
be bufferred and unknown to the operating system, you won't understand
what setvbuf refers to.

# fork() is not part of the C language or its libraries. It is a

As usual, two mistakes: "C language" is not ANSI C. Second, you see
"fork" and your knee jerks without pausing to understand the true
problem, which is how ANSI C file bufferring and interact with program
execution.

# The UNIX API does not define the C language. The Windows API does not
# define the C language.

ANSI <stdio.h> does not define the language.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I have no respect for people with no shopping agenda.

[Kenny McCormack]

In article <11*************@corp.supernews.com>,
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
....

ANSI <stdio.h> does not define the language.

It should be clear by now that Jack Klein defines the language.

[Robert Gamble]

SM Ryan wrote:

Jack Klein <ja*******@spamcop.net> wrote:

# The question is off-topic and any attempts to answer it in detail are

It is most definitely on-topic unless you think setbuffer, setvbuf,
printf, stdout, and _everything_ else in <stdio.h> is off-topic.
The question is about how does stdio bufferring work, not how does
fork work. A similar issue would show up if the program aborts and
appears to lose part of the output: until you know some output can
be bufferred and unknown to the operating system, you won't understand
what setvbuf refers to.

# fork() is not part of the C language or its libraries. It is a

As usual, two mistakes: "C language" is not ANSI C.
It is in this group, but as usual you still can't seem to comprehend
this.
Second, you see "fork" and your knee jerks without pausing to understand the > true problem, which is how ANSI C file bufferring and interact with program
execution.

The use of fork() plays a large part in the behavior being discussed
and a group like comp.unix.programmer would be a much more appropriate
place for this post. Jack was completely correct in what he said and
he couldn't have been more helpful or polite with his reply.

Robert Gamble

[CBFalconer]

Kenny McCormack wrote:

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
...

ANSI <stdio.h> does not define the language.

It should be clear by now that Jack Klein defines the language.

You neglected to quote Jacks informative paragraph, which follows:

The question is off-topic and any attempts to answer it in detail
are off-topic. The topic of this newsgroup is the C language,
which is specifically and completely defined originally by the
two editions of K&R, then, since 1989, by various ANSI/ISO
International Standards.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Antonio]

Robert Gamble wrote:

SM Ryan wrote:

As usual, two mistakes: "C language" is not ANSI C.

It is in this group, but as usual you still can't seem to comprehend
this.

<flame>
Then this group should be renamed to something along the lines of
comp.lang.c.ansi or comp.lang.ansic
</flame>

In case anyone doubts it, the flame was intended to be a joke...

[CBFalconer]

Robert Gamble wrote:

SM Ryan wrote:

Jack Klein <ja*******@spamcop.net> wrote:
.... snip ...
# fork() is not part of the C language or its libraries. It is a

As usual, two mistakes: "C language" is not ANSI C.

It is in this group, but as usual you still can't seem to
comprehend this.

Second, you see "fork" and your knee jerks without pausing to
understand the true problem, which is how ANSI C file bufferring
and interact with program execution.

The use of fork() plays a large part in the behavior being discussed
and a group like comp.unix.programmer would be a much more appropriate
place for this post. Jack was completely correct in what he said and
he couldn't have been more helpful or polite with his reply.

As contrasted to Ryans continuous childish attempts to foul normal
newsreaders by insisting on his non-standard quote mark. It is
best to treat him as a pure troll, and PLONK him. This reduces the
annoyance factor and thence the blood pressure.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

Antonio wrote:

Robert Gamble wrote:

SM Ryan wrote:

As usual, two mistakes: "C language" is not ANSI C.

It is in this group, but as usual you still can't seem to
comprehend this.

<flame>
Then this group should be renamed to something along the lines
of comp.lang.c.ansi or comp.lang.ansic
</flame>

In case anyone doubts it, the flame was intended to be a joke...

Unfortunately there are those among us who would take it
seriously. They are often the same people that flout other useful
standards for no reason other than to annoy. We who restrict the
definition have at least 6 references available:

K&R I
K&R II
C89
C90
C95
C99

all of which can be fairly readily found, and all of which build on
previous work. Most of these have, at one time or another, been
stamped as "THE STANDARD" by national and international
organizations. Before recommending anything else, be sure it is
equally accepted and applicable. For example Posix is an OS
standard, not a language standard. Many systems can use the C
language that can never even approach the Posix standard.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[SM Ryan]

"Robert Gamble" <rg*******@gmail.com> wrote:

# The use of fork() plays a large part in the behavior being discussed

Your knee is jerking too. fork demonstrates the problem in this case,
but the underlying issue is not fork, but has stdio bufferring works.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
You hate people.
But I love gatherings. Isn't it ironic.

[SM Ryan]

# You neglected to quote Jacks informative paragraph, which follows:
#
# >>> which is specifically and completely defined originally by the
# >>> two editions of K&R, then, since 1989, by various ANSI/ISO

Maybe you should re-read K&R 1978 pp 158-177 (chapter 8).

--
SM Ryan http://www.rawbw.com/~wyrmwif/
This is one wacky game show.

[Barry Schwarz]

On Thu, 21 Jul 2005 05:13:48 -0000, SM Ryan
<wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

# You neglected to quote Jacks informative paragraph, which follows:
#
# >>> which is specifically and completely defined originally by the
# >>> two editions of K&R, then, since 1989, by various ANSI/ISO

Maybe you should re-read K&R 1978 pp 158-177 (chapter 8).

You mean the one that says this chapter applies only to Unix.
<<Remove the del for email>>