From stdcxx-dev-return-3532-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Tue May 29 18:32:08 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 51215 invoked from network); 29 May 2007 18:32:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 May 2007 18:32:08 -0000 Received: (qmail 15426 invoked by uid 500); 29 May 2007 18:32:12 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 15416 invoked by uid 500); 29 May 2007 18:32:12 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 15405 invoked by uid 99); 29 May 2007 18:32:12 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2007 11:32:12 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2007 11:32:07 -0700 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l4TIUx3V019825 for ; Tue, 29 May 2007 18:30:59 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 12:31:11 -0600 Message-ID: <465C71EA.4010705@roguewave.com> Date: Tue, 29 May 2007 12:33:14 -0600 From: Martin Sebor Organization: Rogue Wave Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] RE: [jira] Created: (STDCXX-427) SIGSEGV in istringstream::str() References: <26166494.1179958456146.JavaMail.jira@brutus> <7BDB2168BEAEF14C98F1901FD2DE6438868EBF@epmsa009.minsk.epam.com> <46563921.8030505@roguewave.com> <7BDB2168BEAEF14C98F1901FD2DE6438869047@epmsa009.minsk.epam.com> <465779AD.4020201@roguewave.com> <7BDB2168BEAEF14C98F1901FD2DE643886952B@epmsa009.minsk.epam.com> In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE643886952B@epmsa009.minsk.epam.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 18:31:11.0830 (UTC) FILETIME=[8854E760:01C7A21F] X-Virus-Checked: Checked by ClamAV on apache.org Farid Zaripov wrote: >> -----Original Message----- >> From: Martin Sebor [mailto:sebor@roguewave.com] >> Sent: Saturday, May 26, 2007 3:05 AM >> To: stdcxx-dev@incubator.apache.org >> Subject: Re: [PATCH] RE: [jira] Created: (STDCXX-427) SIGSEGV >> in istringstream::str() >> >>> The bug is in that len calculated as highmark - pbase(), >> but pbase() >>> == 0 when buffer opened only in input mode. The begin of >> the buffer is >>> always >>> this->_C_buffer with any openmode. So len = highmark - _C_buffer is >>> correct, I think. >> In input mode (only) the function is supposed to return: >> >> string(eback(), egptr()); >> >> In output mode (or input | output) the function must return: >> >> string(pbase(), high_mark); >> >> So unless I'm missing something the program below should be a >> valid (albeit incomplete) test case. Let me know what you think. > > Formally the test case is valid, but logically, I think, the buffer > pointers and the buffer > itself should be in consistency, and in this test eback() and pbase() > are changed from > the real begin of the buffer of the std::stringbuf. I'm not sure I understand. If the test case is valid but doesn't pass, the implementation doesn't conform. The only way this could be acceptable is if the requirement in the standard was unclear or didn't make sense (in which case we'd need to open an issue against the standard to clarify/correct the requirement). To me the requirement in the standard is clear and makes sense. Does it not to you? Martin