On Thu, Aug 09, 2001 at 05:05:26PM -0700, Ryan Bloom wrote: > On Thursday 09 August 2001 15:33, Greg Stein wrote: > > On Wed, Aug 08, 2001 at 01:40:33AM -0400, Cliff Woolley wrote: >... > > > As of late, the rule has become this: individual buckets can contain no > > > more than an apr_size_t. A brigade can have total length up to an > > > apr_off_t. So apr_bucket_split() and friends SHOULD take an apr_size_t, > > > because that's the biggest the bucket can be anyway. Something within > > > ap_http_filter needs to handle the conversion, I'd expect. > > > > FILE, PIPE, and SOCKET buckets can easily be more than "memory-sized". > > Thus, all of the split and partition functions should take an apr_off_t. > > > > When you read, you'll only get back a portion. > > > > So... the "rule" you state ought to be changed. It just doesn't apply to > > certain types of buckets. > > Buckets are buckets. To have different rules for some buckets than others > means that the > API's would be inconsistant. Plus, PIPE and SOCKET buckets always have a -1 > length. > FILE buckets are basically capped at apr_size_t, because having more than > that in one > bucket doesn't really help you anyway. The argument was that every operating > system with > sendfile we support will do a partial write of the file, because 2Gig is too > big to send at one time. > Without this change, we get all sorts of warnings on platforms where > apr_size_t and apr_off_t > aren't the same.
What?! I'm not saying *some* bucket use one size, and the other buckets another size. I'm saying all the split functions should be an apr_off_t. Their content can be larger than apr_size_t, so the split points needs to be an apr_off_t. Cheers, -g -- Greg Stein, http://www.lyra.org/
