Cygwin 64-bit C compiler caching funny (and ending early)

Question

We've been using CygWin (/usr/bin/x86_64-w64-mingw32-gcc) to generate Windows 64-bit executable files and it has been working fine through yesterday. Today it stopped working in a bizarre way--it "caches" standard output until the program ends. I wrote a six line example that did the same thing. Since we use the code in batch, I wouldn't worry except when I run a test case on the now-strangely-caching executable, it opens the output files, ends early, and does not fill them with data. (The same code on Linux works fine, but these guys are using Windows.) I know it's not gorgeous code, but it demonstrates my problem, printing the numbers "1 2 3 4 5 6 7 8 9 10" only after I press the key.

#include <stdio.h>
main ()
{
  char q[256];
  int i;
  for (i = 1; i <= 10; i++)
    printf ("%d   ", i);
  gets (q);
  printf ("\n");
}

Does anybody know enough CygWin to help me out here? What do I try? (I don't know how to get version numbers--I did try to get them.) I found a 64-bit cygwin1.dll in /cygdrive/c/cygwin64/bin and that didn't help a bit. The 32-bit gcc compilation works fine, but I need 64-bit to work. Any suggestions will be appreciated.

Edit: we found and corrected an unexpected error in the original code that caused the program not to populate the output files. At this point, the remaining problem is that cygwin won't show the output of the program.

For months, the 64-bit executable has properly generated the expected output, just as the 32-bit version did. Just today, it has started exhibiting the "caching" behavior described above. The program sends many hundreds of lines with many newline characters through stdout. Now, when the 64-bit executable is created as above, none of these lines are shown until the program completes and the entire output it printed at once. Can anybody provide insight into this problem?

score 2 · Answer 1 · edited May 23 '17 at 11:49

This is quite normal. printf outputs to stdout which is a FILE* and is normally line buffered when connected to a terminal. This means you will not see any output until you write a newline, or the internal buffer of the stdout FILE* is full (A common buffer size is 4096 bytes).

If you write to a file or pipe, output might be fully buffered, in which case output is flushed when the internal buffer is full and not when you write a newline.

In all cases the buffers of a FILE* are flushed when: you call fflush(..). You call fclose(..) or the program ends normally.

Your program will behave the same on windows/cygwin as on linux.

You can add a call to fflush(stdout) to see the output immediately.

for (i = 1; i <= 10; i++) {
    printf ("%d   ", i);
    fflush(stdout);
}

Also, do not use the gets() function.

If your real programs "ends early" and does not write data in text files that it's supposed to, it may be it crashes due to a bug of yours before it finishes, in which case the buffered output will not be flushed out. Or, more unlikely, you call the _exit() function, which will terminate the program without flushing FILE* buffers (in contrast to the exit() function)

Well, (blushes in shame), we found a problem with the code by running it in visual studio on the same case. That fixed, the only problem that remains is the "caching" problem. The 32-bit executable prints many lines of output with no delay. The 64-bit executable waits until the program has completed and *only then* prints the entire output. — user2127595, Apr 18 '14 at 23:53

Cygwin 64-bit C compiler caching funny (and ending early)

1 Answers1