From dev-return-7331-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Tue Apr 15 16:33:42 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 87677 invoked from network); 15 Apr 2008 16:33:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Apr 2008 16:33:41 -0000 Received: (qmail 26498 invoked by uid 500); 15 Apr 2008 16:33:42 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 26431 invoked by uid 500); 15 Apr 2008 16:33:42 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 26413 invoked by uid 99); 15 Apr 2008 16:33:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Apr 2008 09:33:42 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Apr 2008 16:32:57 +0000 Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com [10.22.129.22]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m3FGX9dw014902 for ; Tue, 15 Apr 2008 16:33:09 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: svn commit: r647908 - in /stdcxx/trunk/tests: self/0.printf.cpp src/fmt_defs.h src/printf.cpp Date: Tue, 15 Apr 2008 10:33:02 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: svn commit: r647908 - in /stdcxx/trunk/tests: self/0.printf.cpp src/fmt_defs.h src/printf.cpp Thread-Index: Acieth+gTdsshXjYTOKgSo+7opf/VwAYBAOQ References: <20080414171556.87A691A9832@eris.apache.org> <48039BE0.4020702@roguewave.com> <4803BD77.5020405@roguewave.com> <4803CF95.5010801@roguewave.com> <480436DE.3040502@roguewave.com> From: "Eric Lemings" To: X-Virus-Checked: Checked by ClamAV on apache.org =20 Question. What was the rationale for using old, C printf-like functions in the test drive to begin with? Seems like a C++ library, especially a C++ standard library implementation, would use C++ streams instead. Brad. > -----Original Message----- > From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor > Sent: Monday, April 14, 2008 11:02 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r647908 - in /stdcxx/trunk/tests:=20 > self/0.printf.cpp src/fmt_defs.h src/printf.cpp >=20 > Travis Vitek wrote: > > Travis Vitek wrote: > >> Unless I'm totally misunderstanding you (it seems that I=20 > may be), this > >> would limit maximum command line length to 256 characters. > >> > >=20 > > Okay, I think I'm finally seeing the light. My=20 > understanding of how this > > was intended to work was totally wrong. I had mistakenly=20 > thought that if > > the maxsize format specifier (%{*} or %{n}) wasn't provided that > > rw_vasnprintf() would intellegently switch to a dynamic=20 > buffer and leave > > the original user provided buffer alone. >=20 > Heh. I just responded to your other post agreeing with your first > approach. Either I don't remember how it was supposed to work or > I managed to confuse myself (or let you confuse me ;-) >=20 > >=20 > > I now understand that if the caller uses a static buffer, they are > > expected (required) to indicate maximum number of characters to be > > written to the buffer using the previously mentioned format=20 > specifier. > > With that specifier, maxsize would get set and the guard check and > > free() call are avoided. >=20 > I thought that's how it was supposed to work until you brought up > the _rw_system() use case which certainly shouldn't be limited to > 256 characters. >=20 > > The guard bytes that were added in > > [r351515|http://svn.apache.org/viewvc?view=3Drev&revision=3D351515] = will > > usually detect that a buffer was not allocated with a=20 > previous call to > > _rw_bufcat(), and the assertion will trigger. Unfortunately=20 > there wasn't > > a comment there to indicate that this was expected behavior=20 > and that the > > caller was using the function improperly. > >=20 > > So after a whole day of this I think I have the appropriate=20 > solution. It > > is consistent with what Martin did in r351515, so I have=20 > that much going > > for me. I'm planning on committing the fix shortly. >=20 > Oh, goody :) I see I managed to confuse you too ;-) >=20 > rw_vasnprintf() was modeled after GNU asprintf() and vasnprintf() > http://www.gnu.org/software/libc/manual/html_mono/libc.html#Dy > namic-Output > (I'm not sure if the latter is GNU or someone else's invention but > it's out there). I *think* it's supposed to handle the _rw_system() > use case. >=20 > Martin >=20 >=20