title: Is the inconsistency of C++'s istream::eof() a bug in the spec or a bug in the implementation?
body: <p>The following program demonstrates an inconsistency in the way that std::istream (specifically in my test code, std::istringstream) sets eof().</p>
  
  <pre><code>#include &lt;sstream&gt;
  #include &lt;cassert&gt;
  
  int main(int argc, const char * argv[])
  {
      // EXHIBIT A:
      {
          // An empty stream doesn't recognize that it's empty...
          std::istringstream stream( "" );
          assert( !stream.eof() );        // (Not yet EOF. Maybe should be.)
          // ...until I read from it:
          const int c = stream.get();
          assert( c &lt; 0 );                // (We received garbage.)
          assert( stream.eof() );         // (Now we're EOF.)
      }
      // THE MORAL: EOF only happens when actually attempting to read PAST the end of the stream.
  
      // EXHIBIT B:
      {
          // A stream that still has data beyond the current read position...
          std::istringstream stream( "c" );
          assert( !stream.eof() );        // (Clearly not yet EOF.)
          // ... clearly isn't eof(). But when I read the last character...
          const int c = stream.get();
          assert( c == 'c' );             // (We received something legit.)
          assert( !stream.eof() );        // (But we're already EOF?! THIS ASSERT FAILS.)
      }
      // THE MORAL: EOF happens when reading the character BEFORE the end of the stream.
  
      // Conclusion: MADNESS.
      return 0;
  }
  </code></pre>
  
  <p>So, eof() "fires" when you read the character <em>before</em> the actual end-of-file. But if the stream is empty, it only fires when you actually attempt to read a character. Does eof() mean "you just tried to read off the end?" or "If you try to read again, you'll go off the end?" The answer is inconsistent.</p>
  
  <p>Moreover, whether the assert fires or not depends on the compiler. Apple Clang 4.1, for example, fires the assertion (raises eof() when reading the preceding character). GCC 4.7.2, for example, does not.</p>
  
  <p>This inconsistency makes it hard to write sensible loops that read through a stream but handle both empty and non-empty streams well.</p>
  
  <p>OPTION 1:</p>
  
  <pre><code>while( stream &amp;&amp; !stream.eof() )
  {
      const int c = stream.get();    // BUG: Wrong if stream was empty before the loop.
      // ...
  }
  </code></pre>
  
  <p>OPTION 2:</p>
  
  <pre><code>while( stream )
  {
      const int c = stream.get();
      if( stream.eof() )
      {
          // BUG: Wrong when c in fact got the last character of the stream.
          break;
      }
      // ...
  }
  </code></pre>
  
  <p>So, friends, how do I write a loop that parses through a stream, dealing with each character in turn, handles every character, but stops without fuss either when we hit the EOF, or in the case when the stream is empty to begin with, never starts?</p>
  
  <p>And okay, the deeper question: I have the intuition that using peek() could maybe workaround this eof() inconsistency somehow, but...holy crap! Why the inconsistency?</p>