----- 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.)
