Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 5584 invoked from network); 25 Jul 2006 18:05:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Jul 2006 18:05:20 -0000 Received: (qmail 64459 invoked by uid 500); 25 Jul 2006 18:05:20 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 64449 invoked by uid 500); 25 Jul 2006 18:05:20 -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 64438 invoked by uid 99); 25 Jul 2006 18:05:20 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Jul 2006 11:05:20 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.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, 25 Jul 2006 11:05:18 -0700 Received: from qxvcexch01.ad.quovadx.com (qxvcexch01.ad.quovadx.com [192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.4) with ESMTP id k6PI4vAK012362 for ; Tue, 25 Jul 2006 18:04:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: problem in temp_buffer Date: Tue, 25 Jul 2006 12:04:04 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: problem in temp_buffer Thread-Index: AcawER6fJAAH7J0yQcO665ZmieXIagAA4FNg From: "Nicole Willson" To: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Well, I just ran the testcase in the bug without issue - so that's not the exact problem. =20 -----Original Message----- From: Martin Sebor [mailto:sebor@roguewave.com]=20 Sent: Tuesday, July 25, 2006 11:38 AM To: stdcxx-dev@incubator.apache.org Subject: Re: problem in temp_buffer Nicole Willson wrote: > I just noticed that it isn't ignored, but I still don't understand the > purpose. _RWSTD_TMPBUF_SIZE is #defined to the size of the static temporary buffer. When get_temporary_buffer() is invoked to request a buffer whose size in bytes is less than or equal to _RWSTD_TMPBUF_SIZE and the static buffer is not in use yet the function returns the address of the buffer to the caller. Otherwise it tries to allocate the buffer dynamically on the heap. If the allocation fails, get_temporary_buffer() fails by returning pair(0, 0). > If the check fails, it simply procedes to __rw_allocate. > Since the code I am tracking has sent in a block so large that the=20 > code will not be able to address it all, I would think it would stop here. > Is __rw_allocate supposed to handle this? __rw_allocate() is just a wrapper around operator new. It throws an exception on failure. __rw_tmpbuf() catches it and returns pair(0, 0) instead. What exactly is the issue you are tracking down? Some compilers are known to fail the test (with various symptoms) due to a bug. See, for example http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=3D1605 Martin >=20 > -----Original Message----- > From: Nicole Willson [mailto:willson@roguewave.com] > Sent: Tuesday, July 25, 2006 11:15 AM > To: Stdcxx > Subject: RE: problem in temp_buffer >=20 > I'm tracking down an issue with temp_buffer in stdlib/utilities. I'm=20 > confused by a piece of code in source/stdlib/tmpbuf.cpp: > =20 > if (nbytes <=3D _RWSTD_TMPBUF_SIZE) { > =20 > if (1 =3D=3D _RWSTD_THREAD_PREINCREMENT (__rw_buffer_busy, = false)) > { > =20 > *pptr =3D buffer; > =20 > // static buffer used, its usage counter stays non-zero > return _RWSTD_TMPBUF_SIZE / size; > } > =20 > // static buffer not used, decrement its usage counter > _RWSTD_THREAD_PREDECREMENT (__rw_buffer_busy, false); > } > =20 > _TRY { > *pptr =3D __rw_allocate (nbytes, 0); > } > _CATCH (...) { > *pptr =3D 0; > nbytes =3D 0; > } > =20 > return nbytes / size; >=20 > =20 > What is the purpose of the check against _RWSTD_TMPBUF_SIZE if it is=20 > ignored? >=20 > Nicole Willson >=20 > Consulting Engineer >=20 > Rogue Wave Software, Inc. >=20 > A Division of Quovadx >=20 > 303-545-3210 >=20 > =20 >=20