[llvm-bugs] [Bug 28217] New: istream::readsome() does not construct sentry

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=28217

            Bug ID: 28217
           Summary: istream::readsome() does not construct sentry
           Product: libc++
           Version: 3.5
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lavr at ncbi.nlm.nih.gov
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com
    Classification: Unclassified

Since LLVM implementation of istream::readsome() does not seem to construct the
sentry object (which is required in C++11 and which was also implicitly
required by an older standard), reading past EOF may cause applications to
enter endless loops.

Consider the following scenario: code reads a stream with readsome() in a
do..while(stream) loop.   At the EOF in_avail() returns -1, which makes
readsome()  assert an eofbit.  operator bool returns true on such a stream,
restarting the loop.  Since sentry is not constructed, no additional bits are
set in the stream state when readsome() is re-entered, this process continues
indefinitely.

Had sentry been constructed, the failbit would have been set, breaking the
loop.

Alternatively, the older revision of the standard explicitly noted that if
stream wasn't good(), readsome() must set failbit on such a stream (this was in
addition to the implicit rule for all unformatted input functions to construct
sentry first before proceeding with the input).

basic_istream<_CharT, _Traits>::readsome(char_type* __s, streamsize __n)
{
    __gc_ = 0;
    streamsize __c = this->rdbuf()->in_avail();
    switch (__c)
    {
    case -1:
        this->setstate(ios_base::eofbit);
        break;
    case 0:
        break;
    default:
        read(__s, _VSTD::min(__c, __n));
        break;
    }
    return __gc_;
}

-- 
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/20160620/30c4449b/attachment.html>