[LLVMbugs] [Bug 13667] New: Bugs in basic_filebuf::sync()

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Aug 22 11:33:50 PDT 2012


             Bug #: 13667
           Summary: Bugs in basic_filebuf::sync()
           Product: libc++
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: tuhertz at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

1. sync() should reset it’s external buffer pointers. 
Remaining characters should be discarded once sync() called. If don’t, garbage
characters can be inserted to the front of external buffer in underflow().
Because underflow() copies remaining characters in external buffer to it’s
front. This results wrong characters insertion when seekpos() or seekoff() is

this line should be inserted in sync() just before return:
__extbufnext_ = __extbufend_ = __extbuf_;

2. sync() should use length() rather than out() to calculate offset.
Reversing iterators and calling out() to calculate offset from behind is
working fine in stateless character encoding. However, in stateful encoding,
escape sequences could differ in length. As a result, out() could return wrong

For example, if we have internal buffer converted from this external sequence:
(capital letters mean escape sequence)
… a a a a B b b b b

out() produces this sequence. 
b b b b A a a a a

Because out() inserts escape sequence A rather than B, result sequence doesn't
match to external sequence. A and B could have different lengths, result offset
could be wrong value too.

length() method in codecvt is right for calculating offset, but it counts
offset from the beginning of buffer. So it requires another state member
variable to hold state before conversion.

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list