Bill Patterson wrote in a message to Mike Bilow:

 MB> Both your instructor and this book are wrong.  As many people 
 MB> here have been trying to convince you, the actual wording of 
 MB> Section 7.9.5.2 of the ANSI C standard explicitly says that 
 MB> fflush() is defined only for output streams:
 MB> 
 MB>    int fflush(FILE *stream);
 MB> 
 MB>    If 'stream' points to an output stream or an update stream in 
 MB>    which the most recent operation was not input, the 'fflush' 
 MB>    function causes any unwritten data to be delivered to the host 
 MB>    environment to be written to a file; otherwise, the behavior is 
 MB>    undefined.

 BP> It might be undefined, but.... SAMS, Microsoft (C for 
 BP> yourself), Borland, and the Turbo C Bible all teach it that way.

This argument is growing somewhat pointless, but I should point out that
the term "undefined behavior" is itself explicitly defined by
Section 3.16 of the ANSI C standard:

   Behavior, upon use of a nonportable or erroneous program construct, of 
   erroneous data, or of indeterminately valued objects, for which this 
   International Standard imposes no requirements.  Permissible undefined 
   behavior ranges from ignoring the situation completely with unpredictable 
   results, to behaving during translation or program execution in a 
   documented manner characteristic of the environment (with or without the 
   issuance of a diagnostic message), to terminating a translation or 
   execution (with the issuance of a diagnostic message).

In other words, an ANSI C compiler is free to do whatever it wants when you
do something undefined, such as calling fflush() against an input stream. 
One compiler could ignore the call and do nothing, a second compiler could
delete any characters waiting to be read, and a third compiler could
terminate the program and issue a diagnostic message.  If you want to write
code like that, then feel free -- but it is foolish for you to argue that
it is good practice.
  
-- Mike


---