Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: domain of msebor@gmail.com designates
 209.85.200.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=uJGWWUFpMEIDHVDE5fwlwCnQXrBiPmVrKozgTKy/Hd0POk8UPNBuB+R5W7jNgWcVS3XPw32mymMe45MEqo6lVzhyUooJZGhpY7qk+e2sgc9Yb0Ld7RGTyEz63SF8/YtUocMPfqLZ9OwP0Q7sLGrfuYs87TU6FB0/XqYgiG5CKBY=
Message-ID: <480436DE.3040502@roguewave.com>
Date: Mon, 14 Apr 2008 23:02:22 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r647908 - in /stdcxx/trunk/tests: self/0.printf.cpp
 src/fmt_defs.h src/printf.cpp
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>
 <CFFDD219128FD94FB4F92B99F52D0A499AA80C@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA80C@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Travis Vitek wrote:
> 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.

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 ;-)

> 
> 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.

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.

> The guard bytes that were added in
> [r351515|http://svn.apache.org/viewvc?view=rev&revision=351515] 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.

Oh, goody :) I see I managed to confuse you too ;-)

rw_vasnprintf() was modeled after GNU asprintf() and vasnprintf()
http://www.gnu.org/software/libc/manual/html_mono/libc.html#Dynamic-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.

Martin