> >So, there are two answers to this that I see. #1, tell
> >the programmer that (s)he is out of luck if (s)he doesn't understand
> >the code. #2, actually copy all the data.
>
> So then the rule has to be that if call a apr_brigade_* function that
> can generate more than APR_BUCKET_BUFF_SIZE data in a single call,
> then that brigade has to be output before the buffer is reused or
> goes out of scope?
> It's hard to see how that fits well into a general brigade API.
It's a trade-off. I'm not saying this code is correct, this is the first-stab, and it is a general idea or design.
I realize that, I was commenting that it while sometimes #1 is acceptable, it looks like it would be difficult to understand the rules, so that #2 would probably be the better approach.
> One other optimization that I noticed would probably be useful would
> be to have apr_brigade_putstrs written at the same level as
> apr_brigade_write such that you save the memcpy of apr_brigade_write
> after the apr_vsnprintf.
You lost me here. I am not at all worried about optimizations right now.
I know, just pointing it out.
My biggest problem with this paragraph, is that apr_vsnprintf doesn't have
anything to do with apr_brigade_putstrs and apr_brigade_write, so I don't
see the connection.
Sorry, apr_brigade_vprintf, not apr_brigade_putstrs.
-- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
