"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> ----- Original Message -----
> From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 01, 2001 11:15 AM
> Subject: Re: cvs commit: httpd-2.0/modules/http http_protocol.c
>
>
> > From: "Jeff Trawick" <[EMAIL PROTECTED]>
> > Sent: Wednesday, August 01, 2001 6:55 AM
> >
> >
> > > > Modified: modules/http http_protocol.c
> > > > Log:
> > > > Restore to 1.333 state (problematic, in that we could be facing >(size_t)
> > > > bytes, but better till I figure out the _right_ fix.
> >
> > > > - &asmuch) != APR_SUCCESS) {
> > > > + &r->remaining) != APR_SUCCESS) {
> >
> > > I guess you know that r->remaining is apr_off_t but ap_get_brigade()
> > > wants apr_size_t *? (warnings now on AIX at least)
> >
> > That's why that (borked) patch went in in the first place, before I reverted.
> >
> > > Is there a reason why r->remaining can't be apr_off_t?
> >
> > (can't be apr_size_t?) We aught to transition all the send/recv/byterange
> > code to apr_off_t. What about the converse? Accept (and limit) an apr_off_t
> > to ap_get_brigade? All the other brigade semantics (except read) take an
> > apr_off_t. (Individual buckets take apr_size_t.)
>
> That made little sense. I'm suggesting that all the http-layer code should be
> ultimately changed to properly support apr_off_t, the raw read/write stuff has
> to be apr_size_t (it's in memory after all, and sendfile doesn't appear to really
> support apr_off_t ranges on som platforms.)
no complaints from me with that direction... I can't claim to vouch
for it as the right thing to do
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
