>Martin Sebor wrote:
>
>[EMAIL PROTECTED] wrote:
>>
>> URL: http://svn.apache.org/viewvc?rev=647908&view=rev
>> Log:
>> 2008-04-14 Travis Vitek <[EMAIL PROTECTED]>
>>
>> STDCXX-857
>> * tests/src/fmt_defs.h: Add flag to struct Buffer to indicate
>> who owns the allocated buffer.
>
>I wonder if this flag is really necessary give the maxsize
>member of Buffer whose purpose was to avoid reallocation
>(the implementation may have fallen short of that goal):
>http://svn.apache.org/viewvc?view=rev&revision=381880
>
I don't think I can use the maxsize field for this, but I have a bit of
confusion about this maxsize member.
If maxsize != _RWSTD_UINT_MAX, then the user has provided the necessary
format specifier (i.e. a leading %{*} or %{n}) to tell us not to grow
the buffer past a set length. We are still allowed to grow the buffer,
just not past this limit. Since we are allowed to grow the buffer, even
if maxsize is set, I need some way to indicate that I don't know who
allocated the buffer or where it came from.
Now I know that I could have stolen a bit from maxsize for a flag, but I
didn't want to do that. The additional size_t field didn't seem all that
expensive considering that these buffer objects are allocated on the
stack in a call to a formatted output function.
I just noticed that the code in fmt_bits.cpp uses rw_asnprintf()
expecting that the buffer reallocation done internally would free the
input buffer if necessary. Previously that might have caused the assert
that my change was supposed to fix. Now that code might leak the buffer.
So I'm putting together a patch to fix that now.
In fixing that, I noticed that we have a function rw_vasnprintf() is
defined in printf.cpp, but it isn't declared in rw_printf.h. That
function is declared in each of tests/src/{ctype, driver, exception,
process}.cpp. For a clean fix I'd like to use the function in
test/src/fmt_bits.cpp, but I'd prefer to not forward declare in another
place. Is there some motivation to not declare the function in the
appropriate place. The only reason I can think of to not do so would be
introducing <stdarg.h> into one of the test headers, but that doesn't
seem like it should be a problem because we are doing it in all of the
previously mentioned source files.
Travis
