> No. There really aren't many sendfile implementations that allow you to > transmit more than an apr_size_t, if you start digging the man pages. > Afraid this was a concensus decision make while you were on holiday.
Ummm, no it wasn't. You mentioned it on the mailing list and both Bill and I said it wasn't appropriate for a bucket to be limited to apr_size_t bytes, and then you committed a huge change to make it all consistent. It was better than the previous mishmash, so I saw no reason to veto it, but you can't call that a concensus (not even a lazy one). > Since buckets are atomic units, > they need to correspond to an atomic sendfile/read/whatever. No they aren't. They are buckets of data -- nothing to do with atomicity. > The -brigade- is effectively unlimited. But individual buckets represent one > 'apr_size_t' worth of data. The code became immensely less complex, and > since > nobody else worked on buckets type/data safety, I fixed this to be consistent > through the server. Consistency is good. > > First off, that the point should be an apr_off_t. > > -1, and that's a veto, until you (or anyone else) writes a proper patch to > handle all apr-util and http buckets paying attention to the size arguments, > throughout, and mapping between size and len and off. Until that happens, > this is a size_t. Great, so now the implementation works but the interface is wrong. Guess which is harder to fix after a major release? I think its fine that the code has been cleaned up, but the fact is that this interface will change back to being apr_off_t at some point. And if you don't like that, then sorry -- I'd rather veto your commit and go back to the inconsistent state of warnings on win32 than allow an interface to persist that is just plain wrong. ....Roy
