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:[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 > >
