1
#include <stdio.h>
#include <stdlib.h>

int main()
{
    int i,N;
    for(i=0;i<5;i++)
    {
        printf("Enter The Number \n");
        scanf("%d", &N);
        printf("HELLO %d \n",N);
    }
    return 0;
}

When i execute the above code in the NetBeans then the output is not being executed line by line all the output is executed together i.e once when the loop end...The problem is printf and scanf are not working

mafso
  • 5,433
  • 2
  • 19
  • 40
The Judge
  • 11
  • 3
  • 2
    Your code looks ok. Likely that your IDE has problems/settings issues. – P.P Jun 21 '14 at 18:20
  • What is your exact input and output? – mafso Jun 21 '14 at 18:23
  • Have you tried adding `fflush(stdin)` as the last line of the loop? I am not a C programmer, but seems like that's what helps flushing out the input stream. Though on my `Cygwin` this code is working fine, under `gcc` compiler :-) – nIcE cOw Jun 21 '14 at 18:32
  • 4
    @nIcEcOw. That's UB. Windows defines it, however, afaik (but this question is not tagged as Windows). – mafso Jun 21 '14 at 18:34
  • @mafso: `UB` means? Like I said, I am not a C programmer, so pardon my mistake if any :-) – nIcE cOw Jun 21 '14 at 18:40
  • 1
    @nIcEcOw; UB = undefined behavior: You can't do it in code strictly conforming to the C standard, which does not allow flushing read buffers. Your suggestion is maybe a solution for OP's problem (we don't know much about it, though, because OP doesn't provide the input she gave and the output she got) if this software is supposed to run on a Windows machine only. But that's not portable (and doesn't work e.g. on most Linux machines). – mafso Jun 21 '14 at 18:46
  • Compiled without errors or warnings, and ran as expected, on SUSE Linux w/gcc compiler. – Mahonri Moriancumer Jun 21 '14 at 18:47
  • 3
    Your problem is quite simple: Netbeans (re-)directing IO to itself instead a console causes the C Runtime to detect no interactive devices connected, meaning STDIN and STDOUT are default-buffered, instead of line-buffered or unbuffered. You won't have any trouble executing the exact same program outside the IDE. Workaround: Manually disable buffering or add `fflush(STDOUT)`-statements. – Deduplicator Jun 21 '14 at 18:51
  • No idea what people here are talking about lol, none of that is true, just type 'fflush(stdin);' (in windows) or '_flushall();' in linux before the scanf use line. As simple as that. – Zach P Jun 21 '14 at 21:22
  • @user3195614: My glibc doesn't have a `_flushall` function, I don't know it, it's not standard… What are _you_ talking about? – mafso Jun 21 '14 at 23:02
  • @user3195614: All the world is a MAC (unless its a VAX, Windows, Linux, a BSD, a microprocessor, ...). I hope you get the drift. And undefined behavior does not mean it will blow up on you now, but it might the next time, or some indeterminate time later. – Deduplicator Jun 22 '14 at 00:47
  • @Mafso try and use 'fflush(stdin);' although it depends on OS – Zach P Jun 22 '14 at 06:40

1 Answers1

3

Your description of the problem is actually quite good:

Many C Runtime libraries can detect whether stdout is connected to an interactive device (console window / terminal) or not.
Depending on that, the default buffering mode is selected.

Execute the program on a terminal / in a console window, and you get the standard buffering for interactive devices instead.

Alternatively, calling

setvbuf(stdout, 0, _IOLBUF, BUFSIZ);

before any other operations on that stream will set the stdout stream to default line-buffered operation.

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
  • Just out of curiosity, I've already encountered this sometimes: What are `STDOUT` and `STDIN`? Is this a special Windows thing? And are they different to standard `stdout` and `stdin`? – mafso Jun 21 '14 at 19:03
  • @mafso: No, it's just bad capitalisation, which I obviously sometimes do as well. – Deduplicator Jun 21 '14 at 19:06