[llvm-bugs] [Bug 35335] New: strstreambuf::sgetn reads wrong bytes

[via llvm-bugs]

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

            Bug ID: 35335
           Summary: strstreambuf::sgetn reads wrong bytes
           Product: libc++
           Version: 4.0
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jens at mooseyard.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

Created attachment 19433
  --> https://bugs.llvm.org/attachment.cgi?id=19433&action=edit
Test case demonstrating the bug.

I've found a bug where a sequence of sputn and sgetn calls on a strstreambuf
ends in an incorrect read. The overview is:

1. Construct strstreambuf with default constructor
2. Call sputn with 1500 bytes
3. Call sgetn (into a large enough buffer to read all the bytes)
4. Call sputn with at least 2597 bytes
5. Call sgetn again (same buffer)

The final sgetn call reads 4097 bytes, not 2597 as expected. (4097 == 1500 +
2597)

This bug seems to occur whenever the total number of bytes written is > 4096.
Apparently the strstreambuf reallocates its internal buffer, and some of its
pointers end up in the wrong place.

Attached is a short test case that demonstrates the bug. It will trigger an
assertion failure when run. The constants kLen1 and kLen2 correspond to the
sizes of the two writes; if these are modified so their total is <= 4096, the
program exits successfully.

ENVIRONMENT:
Mac OS X 10.13.2 beta
Xcode 9.2 beta (9C34b)
MacBook Pro (Retina, 15-inch, Late 2013)

I'm unsure exactly what version of libc++ I have; I'm assuming 4.0 since the
header <__config> contains:
    #define _LIBCPP_VERSION 4000

-- 
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/20171116/bf8fbe61/attachment.html>