Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 12254 invoked by uid 500); 26 Aug 2001 23:34:34 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 12243 invoked from network); 26 Aug 2001 23:34:34 -0000 Errors-To: Message-ID: <076701c12e4c$78411d50$95c0b0d0@roweclan.net> From: "William A. Rowe, Jr." To: "Greg Stein" , References: <20010826020022.E2111@lyra.org> Subject: Re: apr_bucket_simple_split Date: Sun, 26 Aug 2001 11:28:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: 64.125.133.20 1.6.2 0/1000/N From: "Greg Stein" Sent: Sunday, August 26, 2001 4:00 AM > On Sat, Aug 25, 2001 at 05:09:14PM -0400, Cliff Woolley wrote: > >... > > APU_DECLARE_NONSTD(apr_status_t) apr_bucket_simple_split(apr_bucket *a, > > - apr_off_t point) > > + apr_size_t point) > > Euh... why is that an apr_size_t? I thought we just talked about that > earlier this week? A bucket could hold a *lot* more than what can fit in > memory. I could easily have a FILE bucket that is 6gig in size (say, a video > file). A FILE bucket can easily be split without needing to read anything > into memory, so the apr_off_t works quite well. 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. Since buckets are atomic units, they need to correspond to an atomic sendfile/read/whatever. 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. > > { > > apr_bucket *b; > > apr_status_t rv; > > > > - if (point < 0 || point > a->length) { > > + if ((point > a->length) || (a->length == (apr_size_t)(-1))) { > > return APR_EINVAL; > > } > > > > > > Why check to see if a->length is -1? That's a waste of time. If > > a->length is -1, the bucket type should have never registered a split > > function in the first place. > > Untrue. Please explain why a PIPE bucket cannot be split at byte 100? Sure, > it doesn't know its length, but it can easily read in 100 bytes, give you > that, and leave itself as the second part of the split. I agree here, we can split an unknown length pipe bucket at known point. I'd suggest that we really want a constant, APR_BUCKET_UNKNOWN_LEN (which needs to map to MAX_SIZE_T or MAX_OFF_T, see below). But I'm not certain that the apr_bucket_split_simple() should learn how to do this, sounds like a job for apr_bucket_split_indeterminate() or something. > > What we really want to know is if point is > > before the beginning of the bucket or after the end of the bucket. The > > original test gave us that. > > > > What am I missing? > > 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. The original bucket implementors paid no attention to transformations of signedness or integer width. I'd wasted near a week getting the emits out of the code, and this was the straigtest line to something that works. One other obstacle was the number of headaches when sizeof(apr_off_t)==sizeof(apr_size_t), but the signedness changes :( Bill