apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: bug in apr_brigade.c
Date Wed, 23 Jan 2002 18:26:16 GMT
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

View raw message