You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/08/01 13:55:42 UTC
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
wrowe@apache.org writes:
> wrowe 01/07/31 21:08:36
>
> 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.
>
> Revision Changes Path
> 1.339 +1 -4 httpd-2.0/modules/http/http_protocol.c
>
> Index: http_protocol.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
> retrieving revision 1.338
> retrieving revision 1.339
> diff -u -r1.338 -r1.339
> --- http_protocol.c 2001/07/30 04:19:57 1.338
> +++ http_protocol.c 2001/08/01 04:08:36 1.339
> @@ -1435,11 +1435,8 @@
>
> do {
> if (APR_BRIGADE_EMPTY(bb)) {
> - apr_size_t asmuch = bufsiz;
> - if (r->remaining < asmuch)
> - asmuch = (apr_size_t)r->remaining;
> if (ap_get_brigade(r->input_filters, bb, AP_MODE_BLOCKING,
> - &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)
Is there a reason why r->remaining can't be apr_off_t?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> ----- Original Message -----
> From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> To: <ne...@apache.org>
> Sent: Wednesday, August 01, 2001 11:15 AM
> Subject: Re: cvs commit: httpd-2.0/modules/http http_protocol.c
>
>
> > From: "Jeff Trawick" <tr...@attglobal.net>
> > 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 | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <ne...@apache.org>
Sent: Wednesday, August 01, 2001 11:15 AM
Subject: Re: cvs commit: httpd-2.0/modules/http http_protocol.c
> From: "Jeff Trawick" <tr...@attglobal.net>
> 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.)
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Jeff Trawick" <tr...@attglobal.net>
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.)