Eric Lemings wrote:
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.
The rationale was to keep the API super simple, minimize
the proliferation of interfaces (overloads) and code bloat.
The iostream approach to formatting in general is pretty
clunky. Most people, myself including, consider the printf
approach to formatting (keeping the description of the
output format separate from the data being formatted)
easier to work with.
Martin
Brad.
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Monday, April 14, 2008 11:02 PM
To: [email protected]
Subject: Re: svn commit: r647908 - in /stdcxx/trunk/tests:
self/0.printf.cpp src/fmt_defs.h src/printf.cpp
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#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.
Martin
