468,457 Members | 1,563 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,457 developers. It's quick & easy.

program doesn't "seem" to print "hello-out"

The following program doesn't "seem" to print "hello-out". (Try
executing it)

#include <stdio.h>
#include <unistd.h>
int main()
{
while(1)
{
fprintf(stdout,"hello-out");
fprintf(stderr,"hello-err");
sleep(1);
}
return 0;
}
What could be the reason?

Aug 25 '06 #1
16 3874
saurabhnsit2001 wrote:
The following program doesn't "seem" to print "hello-out". (Try
executing it)

#include <stdio.h>
#include <unistd.h>
int main()
{
while(1)
{
fprintf(stdout,"hello-out");
fprintf(stderr,"hello-err");
sleep(1);
}
return 0;
}
What could be the reason?
if you add a line
fflush(stdout);

in the while loop , you will find out what really happenen.
Aug 25 '06 #2
output to stderr goes out ASAP, output to stdout is often buffered up.
If you wait long enough you'll see the output appear.

Aug 25 '06 #3
saurabhnsit2001 wrote:
>
The following program doesn't "seem" to print "hello-out". (Try
executing it)

#include <stdio.h>
#include <unistd.h>
int main()
{
while(1)
{
fprintf(stdout,"hello-out");
fprintf(stderr,"hello-err");
sleep(1);
}
return 0;
}

What could be the reason?
Probably the fact that it shouldn't even compile on a standard C
compiler. There is no such thing as <unistd.h>, nor a sleep
function, in standard C (which is the subject of discussion here).
If you eliminate those things, resulting in:

#include <stdio.h>

int main(void)
{
while(1) {
fprintf(stdout, "hello-out");
fprintf(stderr, "hello-err");
}
return 0;
}

there is never any reason for any output to appear, due to the lack
of any '\n' in the output nor any calls to fflush(stdout). stderr
is unbuffered, so it's output will probably appear. Terminate the
strings with '\n'.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
Aug 25 '06 #4
In article <44***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
....
>Probably the fact that it shouldn't even compile on a standard C
compiler. There is no such thing as <unistd.h>, nor a sleep
Now, that's just bogus. I suppose it could be said to be pedantically
correct if you replace "shouldn't" with "needn't". Pedantically
correct, but useless, of course, like most of the dreck posted to this ng.

Aug 25 '06 #5

Kenny McCormack is a troll; do not respond to him/her. He/she only posts here
as a form of pathetic self-affirmation.

The only way to deal with trolls is to limit your reaction to reminding
others not to respond to trolls.

Information on trolls: http://members.aol.com/intwg/trolls.htm

--

Frederick Gotham
Aug 25 '06 #6
Frederick Gotham wrote:
Kenny McCormack is a troll; do not respond to him/her. He/she only posts here
as a form of pathetic self-affirmation.

The only way to deal with trolls is to limit your reaction to reminding
others not to respond to trolls.
This _is_ bending the rules a bit, isn't it?

I prefer the "high-jack the thread for your own off-topic nonsense"
tactic, myself.

Hmmm. I have no off-topic nonsense to add. Unless this is it.

Yup. That's all I got.
Aug 25 '06 #7

CBFalconer wrote:
#include <stdio.h>

int main(void)
{
while(1) {
fprintf(stdout, "hello-out");
fprintf(stderr, "hello-err");
}
return 0;
}

there is never any reason for any output to appear, due to the lack
of any '\n' in the output nor any calls to fflush(stdout).
Well, that's an interesting answer. If it were true, that would
require every implementation of fprintf to by default allocate an
infinitely large output buffer, and every computer out there to have
infinite memory.

Or have an intelligent fprintf that could recognize repeated patterns
in what's passed to it and compress the output buffer on the fly.
Just 128 bits of repeat count would be enough for most purposes.

Hey! That's (to me) a new, and somewhat useful idea!. Think of all
the logging code that prints out humdrum, mostly repeated strings!

Out of the mouths of .......

stderr
is unbuffered, so it's output will probably appear. Terminate the
strings with '\n'.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
Aug 26 '06 #8
"Ancient_Hacker" <gr**@comcast.netwrites:
CBFalconer wrote:
>#include <stdio.h>

int main(void)
{
while(1) {
fprintf(stdout, "hello-out");
fprintf(stderr, "hello-err");
}
return 0;
}

there is never any reason for any output to appear, due to the lack
of any '\n' in the output nor any calls to fflush(stdout).

Well, that's an interesting answer. If it were true, that would
require every implementation of fprintf to by default allocate an
infinitely large output buffer, and every computer out there to have
infinite memory.
No, it just allows such an implementation. It doesn't require
it. Furthermore, an implementation is not required to support
text files with lines longer than 254 characters, including the
terminating new-line character.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman
Aug 26 '06 #9
Kenny McCormack wrote:
In article <44***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
...
>>Probably the fact that it shouldn't even compile on a standard C
compiler. There is no such thing as <unistd.h>, nor a sleep

Now, that's just bogus. I suppose it could be said to be pedantically
correct if you replace "shouldn't" with "needn't". Pedantically
correct, but useless, of course, like most of the dreck posted to this ng.
Frederick Gotham wrote:
Kenny McCormack is a troll; do not respond to him/her. He/she only
posts here as a form of pathetic self-affirmation.
I don't know about Kenny's other posts, but his point above is
legitimate. Standard C accepts non-standard header files and can link
to library routines, it just doesn't define them, so "needn't" is more
precise. Although the original post didn't define what these
non-ISO-9899 standard header and routine do, you could make an
intelligent guess. ;-)

This newsgroup revels in pedantry, so Kenny's non-abusive and, IMO,
accurate post certainly fits in.

--
Thad
Aug 26 '06 #10
On Sat, 26 Aug 2006 17:04:42 -0600, in comp.lang.c , Thad Smith
<Th*******@acm.orgwrote:
>I don't know about Kenny's other posts, but his point above is
legitimate. Standard C accepts non-standard header files and can link
to library routines, it just doesn't define them, so "needn't" is more
precise.
Strictly speaking the original quote was correct, and Kenny was wrong.
The header was nonstandard.
The header wasn't included in the post.
So the compiler cannot find it, and must issue a diagnostic and stop.
>This newsgroup revels in pedantry, so Kenny's non-abusive and, IMO,
accurate post certainly fits in.
Although it was wrong... :-)

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Aug 26 '06 #11
Mark McIntyre wrote:
On Sat, 26 Aug 2006 17:04:42 -0600, in comp.lang.c , Thad Smith
<Th*******@acm.orgwrote:
I don't know about Kenny's other posts, but his point above is
legitimate. Standard C accepts non-standard header files and can link
to library routines, it just doesn't define them, so "needn't" is more
precise.

Strictly speaking the original quote was correct, and Kenny was wrong.
Strictly speaking the original quote was wrong, and Kenny was correct.
The header was nonstandard.
Yes.
The header wasn't included in the post.
Yes.
So the compiler cannot find it,
No. An implementation is permitted to provide it, and if it does, the
compiler /can/ find it.
and must issue a diagnostic and stop.
Aug 26 '06 #12

"CBFalconer" <cb********@yahoo.com??????:44***************@yaho o.com...
saurabhnsit2001 wrote:
>>
The following program doesn't "seem" to print "hello-out". (Try
executing it)

#include <stdio.h>
#include <unistd.h>
int main()
{
while(1)
{
fprintf(stdout,"hello-out");
fprintf(stderr,"hello-err");
sleep(1);
}
return 0;
}

What could be the reason?

Probably the fact that it shouldn't even compile on a standard C
compiler. There is no such thing as <unistd.h>, nor a sleep
function, in standard C (which is the subject of discussion here).
If you eliminate those things, resulting in:

#include <stdio.h>

int main(void)
{
while(1) {
fprintf(stdout, "hello-out");
fprintf(stderr, "hello-err");
}
return 0;
}

there is never any reason for any output to appear, due to the lack
of any '\n' in the output nor any calls to fflush(stdout). stderr
is unbuffered, so it's output will probably appear. Terminate the
strings with '\n'.
No, the output is appeared. After running the code without "sleep" function,
I got a full screen of interlaced "hello-out" and "hello-err".
Aug 27 '06 #13
[snips]

On Sat, 26 Aug 2006 04:41:39 -0700, Ancient_Hacker wrote:
>there is never any reason for any output to appear, due to the lack of
any '\n' in the output nor any calls to fflush(stdout).

Well, that's an interesting answer. If it were true, that would require
every implementation of fprintf to by default allocate an infinitely large
output buffer, and every computer out there to have infinite memory.
You neglect many options. Not least of which is a system that monitors
output and blocks apparent runaway applications from flooding the system
with pointless crud.
Aug 27 '06 #14

Kelsey Bjarnason wrote:
[snips]

On Sat, 26 Aug 2006 04:41:39 -0700, Ancient_Hacker wrote:
there is never any reason for any output to appear, due to the lack of
any '\n' in the output nor any calls to fflush(stdout).
Well, that's an interesting answer. If it were true, that would require
every implementation of fprintf to by default allocate an infinitely large
output buffer, and every computer out there to have infinite memory.

You neglect many options. Not least of which is a system that monitors
output and blocks apparent runaway applications from flooding the system
with pointless crud.
That would be a good thing. But one suspects that it's a hard AI
problem to tell with any degree of certainty whether a program is
printing crud. Plenty of programs might have good reasons to
occasionally write out large amounts of repeating stuff.

Aug 27 '06 #15
On 26 Aug 2006 15:58:58 -0700, in comp.lang.c , "Harald van D?k"
<tr*****@gmail.comwrote:
>
>The header was nonstandard.

Yes.
>The header wasn't included in the post.

Yes.
>So the compiler cannot find it,

No. An implementation is permitted to provide it, and if it does, the
compiler /can/ find it.
You're wrong but I really can't be bothered to explain why. Just think
"Standard" for a couple of minutes and see if it filters through.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Aug 27 '06 #16
Thad Smith <Th*******@acm.orgwrote:
Kenny McCormack wrote:
In article <44***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
...
>Probably the fact that it shouldn't even compile on a standard C
compiler. There is no such thing as <unistd.h>, nor a sleep
Now, that's just bogus. I suppose it could be said to be pedantically
correct if you replace "shouldn't" with "needn't". Pedantically
correct, but useless, of course, like most of the dreck posted to this ng.

Frederick Gotham wrote:
Kenny McCormack is a troll; do not respond to him/her. He/she only
posts here as a form of pathetic self-affirmation.

I don't know about Kenny's other posts, but his point above is
legitimate. Standard C accepts non-standard header files
Yes. However, ISO C doesn't guarantee that headers specified with <are
files at all. If it had been "unistd.h", he'd have had a point.

Richard
Aug 28 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by zhi | last post: by
1 post views Thread by Philippe C. Martin | last post: by
reply views Thread by chris | last post: by
5 posts views Thread by Jim Bancroft | last post: by
51 posts views Thread by Spidey | last post: by
3 posts views Thread by Miki | last post: by
49 posts views Thread by aarklon | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.