From: musiphil@bawi.org   
      
   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.   
      
   > 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? I hope it's as simple as that, but I'm not sure how consistent   
   that understanding is with what the standard says (which still feels vague):   
      
   * 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.   
      
   > I'm simply saying that complexity is inherent in the problem domain:   
   > the states eof, failed, and bad are distinct.  They overlap in our   
   > minds (and experience) only because of the libraries and operating   
   > systems they've been implemented on.   
      
   I tend to agree that I/O can be inherently complex. I also understand   
   that eof is somewhat distinct, but I don't get (yet) how precisely fail   
   and bad are distinct from each other, nor in what different ways I can   
   deal with the two kinds of errors.   
      
   >> 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?'.   
      
   Yes, if you dig into the standard, you can learn that bad() implies   
   fail() and good() implies !fail(), and with some logic you can infer   
   that effectively you have three MECE states {!fail(), fail() && !bad(),   
   bad()} (modulo eof()). But this is getting far from being intuitive.   
      
   Maybe it doesn't matter as much because I have never had to deal with   
   bad() explicitly, and operator void*/bool() and eof() are all I have   
   needed so far...   
      
   --   
   Seungbeom Kim   
      
      
         [ 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)