On Wed, Jan 23, 2002 at 12:07:33PM -0600, William A. Rowe, Jr. wrote: > We've been through this; read the threads please. But long story short, a > 'bucket' is a unit that _may_ be read into memory (although it need not) > while the 'brigade' may obviously be huge. > > The alternative, buckets > size_t is such a massive rewrite you don't > want to contemplate it ;)
This type confusion just seems horrific. I don't buy into this distinction at all. An apr_off_t represents an offset into a file. apr_size_t should be the size of the bucket/brigade. If we want to do it correctly, I'd say that brigade lengths should be 64-bit ints (apr_int64_t). > Win32 for one, right now. A number of unicies, if anyone ever gets it > together > and actually hacks this out right. I assume OS2 (since 64bit file pointers go > back to the pre-divorce days) but they may not be implemented. Dunno about > NW. Unlikely Unix platforms will ever get largefile support (I coded up the autoconf magic and is listed in APR's STATUS). Some of them (Linux, in particular) disable sendfile() with 64-bit file support. I didn't have the heart to follow through on this. If someone wants to pick it up... > > Nah, it doesn't need to deal with -1 length buckets. > > apr_brigade_length with "read_all" set to 1 will exhaust all buckets > > to get the true length. > > So it's simply dirty, not broken :) It's documented. =) > Buckets can always contain NULLs. Code that assumes otherwise will be bitten > someday [yet another bugtraq expose'.] Oh, you mean embedded NULLs. Perhaps, but I think that's outside of the scope of this function. I'll change the prototype to return a length. Let's get the functions right before anyone actually uses them. =) -- justin
