incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: svn commit: r647908 - in /stdcxx/trunk/tests: self/0.printf.cpp src/fmt_defs.h src/printf.cpp
Date Tue, 06 May 2008 19:25:11 GMT
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.


> Brad.
>> -----Original Message-----
>> From: Martin Sebor [] On Behalf Of Martin Sebor
>> Sent: Monday, April 14, 2008 11:02 PM
>> To:
>> 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|] 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()
>> 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

View raw message