The fopen documentation states:

When the "r+", "w+", or "a+" access type is specified, both reading and writing are allowed (the file is said to be open for "update"). However, when you switch between reading and writing, there must be an intervening fflush, fsetpos, fseek, or rewind operation.

Indeed? A brief experiment, if you please.

This indeed succeeds:

char buff[10]; 
FILE* fp = fopen("c:\\test.txt" ,"r+" ); 
// file contains, say, "1 \n 2 \n 3 \n 4 \n 5 \n" 
fgets(buff, 10, fp); // buff contains "1" 
fgets(buff, 10, fp); // buff contains "2" 
fseek(fp, 0, SEEK_CUR); 
fputs("a" , fp); // succeeds
fclose(fp); 

While this fails miserably:

char buff[10]; 
FILE* fp = fopen("c:\\test.txt","r+" ); 
fgets(buff, 10, fp); 
fgets(buff, 10, fp); 
fflush(fp); 
fputs("a" , fp); // fails 
fclose(fp); 

Stepping into the CRT source gives some conjectured reasons:

(1) fopen with ‘r+’ sets fp->_flag to (_IORW & ~(_IOREAD | _IOWRT)).

(2) fgets adds _IOREAD.

(3) fputs contains code (in _flswbuf), logically equivalent to –

    if (stream->_flag & _IOREAD && !(stream->_flag & _IOEOF))) 
    { 
     stream->_flag |= _IOERR; 
     return (_TEOF); 
    }

with an explicit comment (snip):

/* Note that _IOREAD and IOEOF both being set implies switching 
from read to write at end-of-file, which is allowed by ANSI. */

So indeed an explicit transition is mandated.

(4) fseek contains just such a transition. Code in _fseek_nolock reads:

 /* If file opened for read/write, clear flags since we 
     don't know what the user is going to do next [..snip] */
     if (stream->_flag & _IORW) 
     stream->_flag &= ~(_IOWRT|_IOREAD); 

(5) However, fflush does NOT. It does contain code (in _flush) equivalent to –

if ((stream->_flag & (_IOREAD | _IOWRT)) == _IOWRT [..snip]) 
{ 
     _write([..snip]); 
     if ( stream->_flag & _IORW ) 
     stream->_flag &= ~_IOWRT; 
}

So fflush allows transitioning ONLY from write to read.

This is either a CRT bug (my guess), or a documentation issue. Might it be a subtle ANSI-C conformance thingy (as hinted by the _flswbuf comment) that I’m missing? (it’s still a documentation issue in that case). Opinions are very welcome.

This is almost verbatim a feedback I submitted at MS connect a while ago following a forum advice. The issue was triaged (I imagine) and escalated to the product team, and after a few weeks its status changed to ‘fixed’ without any word of explanation.    Oh well.   Hopefully this post will help someone out there some day.