Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
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: Mon, 14 Apr 2008 19:36:06 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA80C@exchmail01.Blue.Roguewave.Com>
Thread-Topic: svn commit: r647908 - in /stdcxx/trunk/tests: self/0.printf.cpp
 src/fmt_defs.h src/printf.cpp
Thread-Index: AcieeIGgNe9/J1XtQYGZ6oya1JaOsAABqJTQAAWuJrA=
References: <20080414171556.87A691A9832@eris.apache.org>
 <48039BE0.4020702@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA807@exchmail01.Blue.Roguewave.Com>
 <4803BD77.5020405@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA808@exchmail01.Blue.Roguewave.Com>
 <4803CF95.5010801@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA80A@exchmail01.Blue.Roguewave.Com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>


Travis Vitek wrote:
>
>Unless I'm totally misunderstanding you (it seems that I may be), this
>would limit maximum command line length to 256 characters.
>

Okay, I think I'm finally seeing the light. My understanding of how this
was intended to work was totally wrong. I had mistakenly thought that if
the maxsize format specifier (%{*} or %{n}) wasn't provided that
rw_vasnprintf() would intellegently switch to a dynamic buffer and leave
the original user provided buffer alone.

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 specifier.
With that specifier, maxsize would get set and the guard check and
free() call are avoided. 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 previous call to
_rw_bufcat(), and the assertion will trigger. Unfortunately there wasn't
a comment there to indicate that this was expected behavior and that the
caller was using the function improperly.

So after a whole day of this I think I have the appropriate solution. It
is consistent with what Martin did in r351515, so I have that much going
for me. I'm planning on committing the fix shortly.

Travis