From: jklowden@speakeasy.net   
      
   On Sun, 11 May 2014 05:44:01 -0700 (PDT)   
   Seungbeom Kim  wrote:   
      
   > On 2014-05-09 06:11, James K. Lowden wrote:   
   > > On Thu,  8 May 2014 06:39:57 CST   
   > > Seungbeom Kim  wrote:   
   > >>   
   > >> Can you please explain what is the EOF ambiguity of read(2)?   
   > >   
   > > When read(2) returns zero bytes, it may mean that no data   
   > > were pending on a socket with nonblocking I/O, or EOF.   
   >   
   > I thought I'd get an error of EWOULDBLOCK if no data were pending   
   > on a nonblocking socket.   
      
   Quite right.  I was thinking of fread(), which when it returns zero has   
   to be checked with feof() and ferror().  I remembered there was   
   ambiguity, but not the condition.  :-/   
      
   > > If you disassociate a stream from files and sockets, though -- if   
   > > it's "just a stream" -- then we *can* imagine bad independent of   
   > > fail.  If the stream can reflect the physical removal of the   
   > > datasource -- say, an Ethernet plug or USB connection -- it could   
   > > report "bad" in lieu of a read operation.  We can also imagine EOF   
   > > being signified as part of the communcations protocol, not   
   > > requiring a short read to be discovered.  Why not?   
   >   
   > Are you saying that an error from the physical source sets badbit, and   
   > an error purely within the stream layer (e.g. conversion to an integer   
   > from characters that have been read from the source successfully) sets   
   > failbit?   
      
   Not *does*, but could.  The design and semantics of the iostream status   
   word perforce antedate implementation and standardization.   
      
   I'm not making any statement about the standard; I'm just defending the   
   design.  There's a difference between "the last operation failed" (e.g.   
   could not convert) and "the stream is no longer usable" (e.g. the   
   device has been disconnected).   
      
   As currently implemented, afaik there's no way badbit will change state   
   without a failed operation, so bad implies fail.  You would be rightly   
   suprised to find failbit behaving as volatile, spontaneously changing   
   to reflect the device state.  I'm only saying that's an artifact of   
   the current implementation, not the design per se.   
      
   > * badbit indicates a loss of integrity in an input or output sequence   
   >   (such as an irrecoverable read error from a file);   
   > * failbit indicates that an input operation failed to read the   
   > expected characters, or that an output operation failed to generate   
   > the desired characters.   
      
   Right, in the first case the stream is kaput, pushing up daisies, an   
   ex-stream.  Nothing you do, even putting the floppy disk back in the   
   drive, will bring it back.   
      
   In the second case, you stil have a chance.  The tellg() pointer hasn't   
   budged, and you can re-try the input with a different conversion.   
      
   Arguably, it's confusing because the first is a property of the stream   
   and the second is a property of the operation.  Traditionally functions   
   return status -- erc = func(...) -- but the iostream operator syntax   
   precludes that, so the status is stashed in the stream.  The   
   property of the stream becomes, "the last operation failed".   
      
   > >> enum of three enumerators (e.g. { good, fail, bad }) could have   
   > >> been much clearer (assuming that eofbit is independent of the   
   > >> others).   
   > >   
   > > and of course that's what we have, in the form of good(), bad(),   
   > > fail() and eof().  Is it so important that it be an enumerated   
   > > type?  Would that actually simplify anything?   
   >   
   > Again, the difference is in the number of (seemingly) possible states.   
   >   
   > For example, given a simple traffic signal with red, yellow, and   
   > green lights where one and only one of them is ON at any given time,   
   > 'enum { red, yellow, green } state();' is a better interface than   
   > 'bool red(), yellow(), green();' because with the former you know   
   > exactly which one of the three states you are in, and you don't   
   > need to worry 'What if red() and yellow() are both ON?'.   
      
   Agreed.  I think the question boils down to whether or not failbit and   
   badbit represent orthogonal states.   
      
   We know operations can fail without the stream "losing integrity". We   
   can imagine the stream going bad spontaneously (if, say, the operator   
   unmounts the drive) even if current implementation requires a failed   
   operation to report it.  ISTM the two states are quite independent.   
      
   --jkl   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)