[LLVMbugs] [Bug 19497] std::ws sets failbit at eof

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19497

Marshall Clow (home) <mclow.lists at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Marshall Clow (home) <mclow.lists at gmail.com> ---
I responded on the SO question, and I'll repeat it here.

I believe that libc++'s behavior is correct per the standard.

[istream.manip] states (about ws):

Effects: Behaves as an unformatted input function (as described in 27.7.2.3,
paragraph 1), except that it does not count the number of characters extracted
and does not affect the value returned by subsequent calls to is.gcount().
After constructing a sentry object extracts characters as long as the next
available character c is whitespace or until there are no more characters in
the sequence. Whitespace characters are distinguished with the same criterion
as used by sentry::sentry (27.7.2.1.3). If ws stops extracting characters
because there are no more available it sets eofbit, but not fail bit.

and 

[istream::sentry]/2 says (about the constructor of the sentry):
2 Effects: If is.good() is false, calls is.setstate(failbit). Otherwise,
prepares for formatted or > unformatted input. ...and so on…

It seems to me that you can argue that libstdc++'s behavior is reasonable, i.e,
if no characters need to be extracted (since we're at EOF), then there's no
reason to set the fail bit. I've opened an issue with the standards committee
asking for clarification. 

I also answered on StackOverflow, too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140421/1bc5bbee/attachment.html>