[LLVMbugs] [Bug 15446] New: stringbuf randomly changes get area

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15446
           Summary: stringbuf randomly changes get area
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: john at johnmaddock.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code is a reduced test case of what boost::lexical_cast does
internally when converting a string to a number type.  It fails with libc++
Trunk (and Clang Trunk) because stringbuf's get area gets changed during
operator>> :

#include <sstream>
#include <cassert>

template< class BufferType, class CharT >
class stl_buf_unlocker: public BufferType{
public:
    typedef BufferType base_class;
    CharT* pptr() const { return base_class::pptr(); }
    CharT* pbase() const { return base_class::pbase(); }
    void setg(CharT* gbeg, CharT* gnext, CharT* gend){ return
base_class::setg(gbeg, gnext, gend); }
    void setp(CharT* pbeg, CharT* pend) { return setp(pbeg, pend); }
};



int main(int argc, char** argv)
{
   typedef stl_buf_unlocker<std::stringbuf, char>  unlocked_but_t;
   const char* p = "3.141592653589793238462";
   //
   // Internally boost::lexical_cast casts away the constantness and plays a
little fast
   // and loose with the buffer type in order to set the get buffer area:
   //
   std::istringstream is;
   char* start = const_cast<char*>(p);
   char* finish = start + std::strlen(start);
   static_cast<unlocked_but_t*>(is.rdbuf())->setg(start, start, finish);
   long double d;
   is >> d;
   //char c = is.get();
   assert(is.rdbuf()->in_avail() == 0);
   return 0;
}

This is currently causing a lot of Boost.Math code to fail

-- 
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/20130305/b6c9f412/attachment.html>