On Mon, Aug 27, 2001 at 12:00:33AM -0500, William A. Rowe, Jr. wrote: >... > If a bucket represents a networkable/readable/writable part of a conversation,
Here is the problem. A bucket represents *data*. It is entirely independent of the network, or in-memory handling, or persisting to disk, or what have you. Data. Pure and simple. > there is no need for apr_off_t chunks of content. But if you like, we can go > the extra mile and support bigger 'file' buckets, with their own file_length, > their own semantics on bucket_make_file(), etc. The bucket brigade code can > just treat it as an unknown size bucket (if it asks, it will be told, this > is huge, don't ask.) And you can split it, over and over again. The sendfile problem that you bring up is related to the code that delivers a brigade over a socket. It has nothing to do with buckets or those brigades. I just did a search over the code. There are seven instances of code creating FILE buckets. Not a single one of them checks to ensure the file length is within the scope of an apr_size_t. But there is no reason they should. Those buckets represent file contents. Not "file contents, as long as that can fit in memory." Buckets are data. Buckets are not "sendfile-sized chunks of data." As with Roy, I am entirely for consistency of the API, and the work that you did to clean it up is Good. But apr_off_t is the real, potential size of a bucket's data. (and yes, I could also agree with tossing the platform-specific apr_off_t and saying they are apr_int64_t or apr_uint64_t (if the latter, then we would need a const for the "-1" concept we have now)) Cheers, -g -- Greg Stein, http://www.lyra.org/
