stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
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 16:33:02 GMT
 
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: 
> 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
> 
> 

Mime
View raw message