Stas Bekman wrote:
Doh! since my suggested change drops the use of apr_brigade_pflatten, all this magic is no longer needed. just use the grow macro like all other functions do and pass SvPVX to flatter. and whoah, no longer we need the pool object! that's a goodness.
which makes it look very much like my first implementation of
apr_brigade_flatten only, which you objected to because it required looping
through the brigade twice to get the entire brigade - once for
apr_brigade_length, and once for apr_brigade_flatten.
You are correct. I didn't realize that pflatten was a cheat (plus scary comment in apr_brigade_pflatten: 'XXX This is dangerous beyond belief..'). I thought it didn't call apr_brigade_length, but did flatten at one pass. I should have looked at the source. Sorry about that.
but I guess it makes for a better API to give the entire brigade back if no length argument is given, and we did reorder the function a bit, so all is better in the end :)
;)
+ bb = mp_xs_sv2_APR__Brigade(*MARK);
+ if (items > 1) { + /* APR::Brigade->flatten($p, $length); */ + length = SvIV(*(MARK+1));
without the pool argument, these can be wrapped up with mpxs_usage_va_2 + a new
#define mpxs_xs_sv2_bb mpxs_xs_sv2_APR__Brigade
which may not be any clearer, but at least it follows existing patterns.
Yeah, I did do that initially, but thought that you won't like it, so I've kept it your way.
+ mpxs_APR__Brigade_flatten | | ...
apr_brigade_pflatten should now get a different modifier than ~ in apr_functions.map.
why? it's implemented, no?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
