Question

A puzzle that hit me. In some simple test harness code, if I stream too many characters to stdout, the program fails. Strange but very reproducable. This may be a Windows only issue, but it’s easy to see:

#include <iostream>
#include <deque>

using namespace std;

int main() 
{
  deque<char> d;
  char c;

  while (cin.get(c)) d.push_back(c);

  for (deque<char>::reverse_iterator j = d.rbegin(); j != d.rend(); j++)
    cout << (*j);
}

The previous code just loads a stream of chars from stdin and outputs them in reverse order. It works fine for up to 100K or so characters, but dies with “error writing stdout” message in Windows for files that are larger. It always dies with the same character.
A shell command like “cat bigfile.txt | reverse.exe” is all you need to reproduce the problem. Both MSFT and Intel compilers both act similarly.

I realize there may be a buffer on stdout, but shouldn’t that be flushed automatically when it’s filled?

Answer 1

Thanks for all the suggestions, especially to Michael Burr who correctly theorized that the cat command, not reverse.exe, may be failing! That’s exactly what it was.. reverse.exe < bigfile.txt works fine, but cat bigfile.txt | reverse.exe fails with “error writing stdout”.
Now why CAT would fail is also a mystery but at least it’s now not something code related.