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

[saurabhnsit2001]

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?

 

[assiss]

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.

 

[Ancient_Hacker]

output to stderr goes out ASAP, output to stdout is often buffered up.
If you wait long enough you'll see the output appear.

 

[CBFalconer]

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:
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

 

[Kenny McCormack]

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]

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

 

[Clever Monkey]

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.

 

[Ancient_Hacker]

#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

 

[Ben Pfaff]

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.

 

[Mark McIntyre]

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

 

[Guest]

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.

 

[Thad Smith]

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.

> 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.

 

[Chen Shusheng]

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".

 

[Kelsey Bjarnason]

[snips]

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.

 

[Ancient_Hacker]

[snips]

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.

 

[Mark McIntyre]

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

 

[Richard Bos]

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