On Thursday 09 August 2001 15:33, Greg Stein wrote: > On Wed, Aug 08, 2001 at 01:40:33AM -0400, Cliff Woolley wrote: > > On Tue, 7 Aug 2001, Ian Holsman wrote: > > > should the 'point' parameter in the bucket split (shared/notimpl/ & > > > simple) be a 'apr_off_t' or a 'apr_size_t' ? > > > > > > This seems to be the only warning generated from the Win2k build > > > > > > http_protocol.c > > > c:\src\apache\httpd-2.0\modules\http\http_protocol.c(678) : warning > > > C4244: 'function' : conversion from '__int64 ' to 'unsigned int ', > > > possible loss of data > > > > > > the offending parameter is 'readbytes' > > > > > > apr_status_t ap_http_filter(ap_filter_t *f, apr_bucket_brigade *b, > > > ap_input_mode_t mode, apr_off_t *readbytes) > > > > 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. Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
